Domain Modeling Methodology
Enterprise Architecture Law
CBM Componentized Business Model
The vertical ones in the figure are actually subdomains and boundary contexts, and the horizontal ones may be some policy layers, control layers, and execution layers, and there are items one by one in it. These contents can correspond to each in our domain design. Aggregation, then there are many aggregations and many subsystems.
If the aggregation is too detailed, we can't write it so finely, then you may be microservices and modules one by one.
Service Oriented Architecture Design
SOA service-oriented architecture model
SOA is based on the bus. In the bus, asynchronous message queues, synchronous API calls, service registration, etc. need to be completed.
The above can also be plugged, such as process-based application services, third-party interfaces, interactive content, information management, security modules, modeling functions, etc., all functions are plugged on the bus. This situation is based on the bus as the cornerstone, and then plugging and unplugging various contents. Relatively speaking, we can split the business freely, and then connect to this component to communicate and communicate with each other. Based on the same set of standards and the same set of communication protocols, we develop our entire IT architecture.
Whether it is CBM or SOA, these two types were developed five years ago, and they are a bit out of date.
So is there anything newer? There are three newer ones.
use case analysis
To put it simply, it is to use UML language to dismantle all the specific needs of customers. It can be drawn with the cube model of the architect's thinking, or it can be like the above picture, the top is the component model, and the lower left corner is some standard use case analysis. The bottom right is the four plus one model and so on.
There are many, many different variants of the UML language, and many design models.
But the above three models are basically related to the domain, but it is not a proprietary domain model. There are two models in the back. They are only born for the domain, and they are also relatively trendy models. Let’s take a look together.
four-color modeling method
I still remember a game I played when I was a child, one student wrote a note, and then divided the work, some students wrote who, some students wrote where, some students wrote what time, some students wrote what to do, and then combined them Get up and tell a little story.
The four-color modeling method is similar to this game.
- Who, where: PPT (Party/Place/Thing) objects
- What identity: role (Role) object
- how: description: (Description) object
- What to do: Moment-Interval objects
As shown in the picture above, join us to buy things online, place an order, then there will be orders, online banking records, package stubs, etc. These records are behaviors that occurred within a period of time, this is the first red.
Then we follow up with who and where. For example, the user's account is "who", the object of the generated order is books, and employees are looking at the promotion records. "Where" is the geographical location, and the information is green. Content.
The next step is yellow. The yellow color represents the role. For example, the role is the marketing director. This employee is the marketing director, so he wants to check the promotion records of the entire company, and at the same time he is the distributor, so he wants to send a package out.
The last step is blue, blue is a description, and the book has a description.
Connecting these four in series is the four-color analysis method .
Once a very complex scene is turned into a simple description, basically entities and value objects will come out. Generally, green and red will be described by entities or aggregate roots. Yellow and blue can be considered to use value objects, especially blue. Colors are basically value objects, and yellow can also have a consideration between value objects and entities.
Such a method is relatively simple, so it is more suitable for communicating with business personnel. Using such a set of language to describe the business clearly,
Event Storming
What kind of methodology is this? What kind of problem is he trying to solve?
In fact, if we think about it carefully, if you want to split the entire field and model it well, there are actually many problems, such as:
- Evolutionary architecture and iterative development
- Microservice Split and Forward Compatibility
- How to communicate with product sales personnel
- Is there a way to complete microservice splitting in drinking tea and chatting?
Then event storm is a good solution to these problems, it has the following characteristics:
- no need to draw a picture
- No Visio, Word and PPT
- Prepare a dozen sticky notes
- The whole process of chatter and sticker games completes the splitting of microservice modules
Let's take an agile project management system as an example: As
shown in the figure above, this is the first big step in the splitting of microservices, and finally divided into such vertical bars, each vertical bar is actually a microservice.
Of course, there is a second big step:
sort out the relationship between these services, should it be a synchronous call? Or asynchronous messages? What methods need to be provided for communication? What member variables should be provided in each aggregate and entity? After talking about all these clearly, the architecture can be easily designed for class diagrams or ER diagrams.
During the entire incident storm process, until all services are split and the relationship between all services is sorted out, this process does not require drawing pictures, only stickers are needed, but IT is still required for later design codes and system deployment. As for the diagrams and architecture diagrams, these diagrams have nothing to do with our product managers and business parties, but the whole process involves the participation of product managers and business parties without any IT means. This is the highlight of our event storm.