On December 11, the new
DDD
CQRSand event sourcing speech: Changing mindset-looking at Business domain modeling in a more object-oriented way, the author describes the traditional programming method and the football match as a case in the football match
CQRSThe difference.
CQRS as
DDDThe best practices have been widely recognized and popular, the following extracts the PPT part of the article to explain briefly, how to use
CQRSand event Sourcing implementation
DDDSystem.
First, the domain experts define the requirements:
1. One tournament with two teams to attend
2. The game starts at a certain time and can only be started once.
3. After the game is over, statistics points
As a user, you want to see:
1. Name of the team participating in the contest
2. Tournament Start time
3. Contest End Time
4. Score after the end of the match.
Well, after collecting these requirements, what should we do next?
1. How do I determine the first step in modeling?
2. How does it relate to relational databases?
3. How does modeling take account of user actions? Get the data they want to see?
4. What do you care more about when modeling?
The traditional way from above needs, according to the noun or the verb rule, obtains the following class:
Match match
Team Teams
Score Score
Matchservice
The code for the class is shown, and there are meta annotations for ORM such as hibernate:
Cond.
[The post was banq on 2012-12-14 13:52]
Football match: Part Two
It seems simple, but is it object-oriented? Does this conform to the encapsulation principle? This is the model of anemic blood loss, the object has only attributes, there is no way of its own behavior, and some only setter/getter method.
So where do we start to change? How to change?
Not start with the data. But from the beginning, the language is unified.
Let's start again and see how the domain experts describe the requirements:
1. One tournament with two teams to attend
2. The game starts at a certain time and can only be started once.
3. After the game is over, statistics points
From this requirement, we will find that there is an aggregate word Aggregate:match game.
This game model can cover most of the requirements.
Then the match match model is undoubtedly an entity and an aggregate root. It is an important feature of the internal state, and can not directly expose the state, through the aggregation of the root entity and the outside world to interact.
With the entity "match match" model, you can create value objects: Two team names, object team value objects, value objects are immutable.
We can start a game based on the name of a game. We can also end a race, when the value object score score, also has immutability.
This aggregation root "match match" has the following characteristics:
1. Have a life cycle of their own
2. Have their own business boundaries.
3. Overcoming Dangerous Setter Methods
4. Aggregation body: Score score Team team and date models are value objects immutable.
Because they are immutable, we only leave getter methods to them, and the user obtains the view of the data they want through getter methods.
This way, the match match aggregates the root entity's code as follows, which is equivalent to moving the original Matchservice code into the entity class method, no more services:
Football match: Part III
In the match class, we only have getter methods, only the immutable value object provides the external access getter method, if we give the variable state to external access, the external transaction boundary will change the internal state, quite dangerous.
This code represents the rich model, the congestion model, with the following benefits:
1. A model with verbs
2. Binding the behavior of data and operational data.
3. Can respond to a unified language.
In the next step, let's think again, what if we also removed the getter method? So how to produce the view data to the user to see?
At this point, we may have noticed that we are looking at this model from the user's point of view, and we have previously looked at the model from a domain expert's point of view, differing in the requirements of the model.
So, we simply look at the model from reading and writing two aspects, which is
CQRS：
Write models: Unified language, explicit transactional boundaries, complex business logic.
Read the model: specifically for read optimization (caching, etc.), there are different SQL such as
NoSQLAnalysis, a simple class composition.
[The post was banq on 2012-12-14 14:15]
Part IV: Event Sourcing
Next, how to make the data meet these models: how feed it with data, if we have to prop up the skeleton, then the data is the domain model of the blood, how to transfer blood into the model? Data is typically stored in a database or various
NoSQLIn
Use event events. Features of the event:
1. Can describe state change, event-driven status change.
2. Describe exactly what has happened, not what is going to happen or what might happen.
3. Relatively small.
4. No Business logic
5. Can be generated by business methods.
6. Queues can be sent to queue, asynchronously.
So, let's add the event code to the method in the Entity model match:
[The post was banq on 2012-12-14 15:10]
Part V Event Replay
The view model view of the CQRS read operation can be exported from the event, so that we have to save the event, the traditional database + event data will produce duplicate data, must ensure the consistency of the event.
Because serialized events can be saved in the relational database
NoSQLor in a file. We must take
DistributedBusiness? Rather complex, rather than just take a database form, which one? Although relational databases are scary, they are more stable on mapping join query. Relational database storage events can be taken to ensure continuity of events.
When these past events are replayed, the aggregates are able to reactivate themselves.
So the aggregation root entity code to make some changes, increase the method playback event, the state encapsulated in the playback method, you must remove the original ORM meta-annotations.
The code for the match class is changed as follows:
field of Part VI object
Brought about by the change of thinking, we consider that the aggregation root is no longer focused on the field properties, but on the responsibility method and behavior.
For the fields in the aggregation root, we only need fields that can change the behavior of the business methods (Banq Note: state, only the state field can change the business behavior), and the other data is included in the event object.
In the match class, whether to end this state has a large impact on the business behavior, so the code changes are as follows:
Last part: Thinking change
Finally, we compare with traditional programming ideas:
The first step in traditional thinking is to consider the data, separate the data from the behavior, and then model the data into a database table structure schema, which is actually the turbo Pascal of the enterprise.
So the question is: what is the first consideration?
The first thing to consider is the language language, which is the unified language, which uses the unified language in the code, considering what our model can do. It then begins to expose its behavior, the behavior is linked to the data, and the behavior is the data (Banq Note: Instead of the data backwards behavior).
We always ask ourselves:
Why? What does it do? What should be its duty to do?
In this way, we naturally have a separation of concerns, with a
CQRS。
For
CQRSWrite operations: What we're thinking about is, how can this function change the state of the system?
For
CQRSRead operations: We consider: Where do we show users what data Views?
Then, natural events will be introduced:
What has happened in the field;
What state is changed;
Events can also be used as a persistence mechanism.
You can restore the entire history.
Final emphasis: Consider business processes rather than data.
What does the business process look like? What is the name, and what behavior is involved in the change.
So we stand on top of the iceberg: (full text)
Case of DDD CQRS and event sourcing: football match
