More research on architecture, less framework (2): MicroServices and congestion models

We talked about the micro-service of the relationship between DDD, many people still feel very unreal, ddd so complex theory, aggregate root, value object, event traceability, how should we start?

In fact, DDD and object-oriented design, design patterns and other theories have inextricably linked, if not familiar with OOA, OOD,DDD is also bad use. However, when studying these oo theories, people often feel useless, because most of the Java Programmer's development career begins with the study of the classical theory of the layering (Action, Service, Dao), in which we have little chance to use the so-called " Behavioral "design pattern, here is the core reason, is the Java EE Classic Layered development mode is" anemia model. "

In his book "Enterprise Application Architecture Model", Martin Fowler proposed two ways of developing "transactional scripting" and "Domain Model", two of which correspond to "anemia model" and "congestion model" respectively.

Transaction Script Development Mode

The core of a transactional script is the process, which can be thought of as most of the business process is a piece of SQL, a transactional script that makes a single SQL organization a business logic that, when executed logically, uses transactions to ensure the acid of the logic. The most typical is a stored procedure. Of course, in the usual Java EE Classic layered architecture, transactional scripting is often used at the service level.

Using this development approach, objects are used only to transfer data between tiers, where the object is the "anemia model", with only data fields and Get/set methods, and no logic in the object.

We take an example of an inventory deduction scenario:

Business Scenarios
First talk about the business scenario, an order deduction inventory (lock Inventory), this is very simple
Determine if the inventory is sufficient, then deduct the available sales inventory, increase the order occupancy inventory, and then record an inventory change log (as a voucher)

The design of anemia model
First design a stock list stock with the following fields

Design a Stock object (getter and setter omitted)

1
2
3
4
5
6
public class Stock {
Private String Spuid;
Private String skuId;
private int stocknum;
private int orderstocknum;
}
Service Entrance
Design a stockservice, in which the lock method writes the logic
Entry to (SPUID, skuId, num)
Implementing pseudo-code

1
2
3
4
5
6
7
Count = Select Stocknum from stock where spuid=xx and skuid=xx
If Count>num {
Update stock set Stocknum=stocknum-num, Orderstocknum=orderstocknum+num where Skuid=xx and spuid=xx
} else {
Insufficient inventory, deduction failed
}
Insert Stock_log set XX=XX, date= new Date ()
OK, after finishing, if you do better, you can combine update and select count, so you can use a statement to complete the spin, solve the Concurrency problem (master).
Summary:
There is no discovery that in this business area very important core logic-under the order deduction inventory in the operation process, the stock object does not appear at all, is the database operation SQL, so-called business logic is composed of more than one SQL. The stock is just a crud data object, and there is no logic.

Martin Fuller definition of "anemia model" is anti-pattern, in the face of simple small system with transaction scripting way to develop no problem, business logic complex, business logic, various states scattered in a large number of functions, maintenance of the expansion of the cost of a sudden come up, anemia model does not implement micro-service Foundation.
Although we use the object-oriented language such as Java development, but in fact, and the process-oriented language is the same, so in many cases, we use the database stored procedures to replace the Java write logic instead, the effect will be better, (PS: With spring boot is not microservices),
Development pattern of domain model

A domain model is the encapsulation of data and behavior and mapping with real-world business objects. Each category has a clear division of responsibilities that allows the logic to be dispersed to the right object. Such an object is the "congestion model".
In practice, we need to make a clear concept that the domain model is stateful and represents something that actually exists. And then the above example, we design the stock object to represent the actual inventory of a commodity, and add the method of business logic on the object

When you do this, you must first restore the inventory object from repository according to the primary key load, and then execute the corresponding lock (num) method to change the state of the Inventory object (the attribute is also one of the states). This object is then persisted to the store by the repository Save method.

To complete the above series of operations, Application,application provides an interface for this integrated operation.

The most important aspect of the domain model development approach is to put the details of the state changes caused by deductions into the inventory object execution, which is the encapsulation of the business logic.
The lock method of the Application object can be compared with the stockservice lock of the transactional scripting method, StockService is fully aware of all the details, once the change (such as inventory is 0 can also be deducted), the service method must be changed , and application this way does not need to change, as long as the inventory object inside the calculation is possible. The code is put in the right place and the calculations are at the right level, and everything is reasonable. This design can make full use of various ood, OOP theory to realize the business logic is very beautiful.

Disadvantages of the congestion model
From the above example, in the repository load to the execution of business methods, and then to save back, it takes a while, but in this process if multiple threads simultaneously request a lock on the inventory inventory, it can lead to inconsistent state, The trouble is that concurrency for inventory is not only difficult to handle but also common.
Anemia models rely entirely on database support for concurrency, the implementation can be simplified a lot, but the congestion model has to be implemented, whether in memory through the lock object, or the use of Redis remote locking mechanism, is more complex than the anemia model and decreased reliability, this is the congestion model challenges. A better approach is to cancel concurrency through an event-driven schema.

Relationship between domain model and micro-service

It says the implementation of the domain model, but what does he have to do with microservices? In practice, this inventory is the aggregate root of a bounding context, and we can assume that an aggregation root is a microservices process.

However, the problem comes again, a stock of inventory must be related to the commodity information, just rely on the redundancy of the inventory in the point of the product ID is not enough, the shelf state of the commodity and so on is the business logic needs, it is not the commodity SKU such as heavy objects introduced this micro-service? Two heavy-duty objects in one service? Such a micro-service is not open ah, or must rely on the commodity library?!

Refer to the next article to complete the loose coupling between domains through an event-driven architecture.

}

OK, after finishing, if you do better, you can combine update and select count, so you can use a statement to complete the spin, solve the Concurrency problem (master). Summary: There is no discovery, in this business area very important core logic-under the Order deduction inventory operation process, the stock object does not appear at all, is the database operation SQL, so-called business logic is composed of multiple SQL. The stock is just a crud data object, and there is no logic. Martin Fuller definition of "anemia model" is anti-pattern, in the face of simple small system with transaction scripting way to develop no problem, business logic complex, business logic, various states scattered in a large number of functions, maintenance of the expansion of the cost of a sudden come up, anemia model does not implement micro-service Foundation. Although we use the object-oriented language such as Java development, but in fact, and the process-oriented language is the same, so in many cases, we use the database stored procedures to replace the Java write logic instead, the effect will be better, (PS: With spring boot is not microservices), The domain model's development model domain models encapsulate data and behavior and map to real-world business objects. Each category has a clear division of responsibilities that allows the logic to be dispersed to the right object. Such an object is the "congestion model". In practice, we need to make a clear concept that the domain model is stateful and represents something that actually exists. Or then the above example, we design the stock object needs to represent the actual inventory of a commodity, and the method of adding business logic to this object, when the order of the single-lock inventory business logic, each time must first from repository according to the primary key load restore inventory This object, The corresponding lock (num) method is then executed to change the state of the Inventory object (a property is also one of the states), and the object is persisted to the store by the repository Save method. To complete the above series of operations is Application,application provides this integrated operation of the interface domain model development method The most important thing is to put the deduction caused by the state changes in the details of the inventory object execution, which is the encapsulation of business logic. The lock method of the Application object can be compared with the stockservice lock of the transactional scripting method, StockService is fully aware of all the details, once the change (such as inventory is 0 can also be deducted), the service method must be changed , and application this way does not need to change, as long as the inventory object inside the calculation is possible. The code is put in the right place and the calculations are at the right level, and everything is reasonable. This design can make full use of various ood, OOP theory to realize the business logicis very beautiful. The disadvantage of the congestion model from the above example, in repository load to the execution of business methods, and then to save back, it takes a while, but in this process if multiple threads simultaneously request a lock on the inventory inventory, it can lead to inconsistent state, The trouble is that concurrency for inventory is not only difficult to handle but also common. Anemia models rely entirely on database support for concurrency, the implementation can be simplified a lot, but the congestion model has to be implemented, whether in memory through the lock object, or the use of Redis remote locking mechanism, is more complex than the anemia model and decreased reliability, this is the congestion model challenges. A better approach is to cancel concurrency through an event-driven schema. The relationship between domain models and microservices is about the implementation of domain models, but what does he have to do with microservices? In practice, this inventory is the aggregate root of a bounding context, and we can assume that an aggregation root is a microservices process. However, the problem comes again, a stock of inventory must be related to the commodity information, just rely on the redundancy of the inventory in the point of the product ID is not enough, the shelf state of the commodity and so on is the business logic needs, it is not the commodity SKU such as heavy objects introduced this micro-service? Two heavy-duty objects in one service? Such a micro-service is not open ah, or must rely on the commodity library?! Refer to the next article to complete the loose coupling between domains through an event-driven architecture.

More architecture, less framework (2): MicroServices and congestion models