Driving design practice in DDD domain--business modeling small Tricks

This article combined with the team in the ECO (community Service System) business modeling process of practical experience, summed up some of the DDD business modeling small tricks, not necessarily perfect, but for our team is very effective, hoping to help others. Later will be the project in the business modeling some of the classic examples put up, to share with you.

The ECO system is an old online system, and its modeling process differs from the business modeling of the new system. Because of carrying historical baggage, eco modeling process is not so pure, very vulnerable to the impact of the old code, into the details of the code, the initial struggle, relying on small steps to run the way to get some embryonic and methodological, the back is more and more smooth, the effect is good.

This article is one of the "DDD" series of articles, other content can be referred to: through the business system refactoring practice DDD. describe a business scene in a sentence

This sentence requires a complete sentence, there is the subject of the object-like, may also have attributive. The subject and object are often the entity/value objects we are looking for. is located is the subject corresponding Entity/value object's behavior method, the adverbial is this case's business rule, often needs to classify to the front entity behavior method, as to the attribute, also will be some business rules, also must gather in the subject corresponding entity.

For example, in a community posting business scenario, we try to use a sentence description: A post author can only post a post in a circle that it has already joined. In contrast to the above method, then "post Author" is the subject, "POST" is the object, "release" is the predicate, "only in its already joined the Circle" is an adverbial. So we can get "post author", "POST" two entities, get "post author" has a "post" behavior method, get a business rule: Post author post the premise is to join the corresponding circle. step fast, keep on iterating

Do not want to eat a big fat, with the prototype of the model to achieve it, in the process of implementation will find a better model, and then constantly iterative perfect, and finally to perfect. short and efficient discussions are important.

Must have discussions with others, especially with the modeling experience of the technical experts or business experts to discuss, targeted discussions, a discussion point not too loose, focus on a requirements module, step-by-step mining business model.

The way to be respected is to discuss the form of the meeting, face-to-face and without restraint.

The length of the discussion should not exceed 1 hours, as in other meetings, more than one hour of efficiency is greatly reduced, the final output is very low; The discussion must focus, preferably with questions to discuss, such as to let you talk about the current modeling process confusion, understanding of the business.

In the course of the discussion, if you encounter unresolved questions or problems that cannot be agreed upon, you cannot spend too much time recording them, then skip them and let everyone go back to think about them and discuss them again next time. write down your modeling thinking process

The process of business modeling is a constant reflection of the problem, the process of thinking I suggest you write down, whether it is the model grass drawing on the whiteboard/paper, or through a full blog expression, are very good. This "write" process allows you to comb the model, to view the model from each case, to look at the shortcomings or pros and cons of the model, and then find a more appropriate model.

I like to use the form of blogging to record every modeling process, including but not limited to: business modeling, business models, code samples. Business modeling--describing the business scenario, modeling the thinking process, the first few times may not be complete, because the business case is considered incomplete, there is no relationship, only need to come up with the current business case requirements of the model can be completed in the next iteration; I usually try to describe the business case in one sentence. , from which the business model is discovered. Business model--thinking through the business modeling front, finally draw the corresponding business model sketch, not the whole business domain all-inclusive model diagram, but the module you are modeling or under the case of the model, as for all-inclusive business model diagram, to the model is relatively mature after the integration Just keep good communication with the associated model in the process of modeling, of course, this kind of communication can avoid as far as possible, after all, the more communication information, indicating the stronger module coupling, this may be the module division unreasonable signal, need vigilance, of course, this is not absolute, see the situation depends. code example-code example is not to complete the entire business model implementation, but through simple code to complete the model demo, and the most important must be written in the form of unit test or write application services to simulate the model's client calls, so that many models are found to be inadequate, In particular, the behavior in the Discovery model of the division and design, better improve the model. At the same time with the code demo, we will have more confidence in the heart, there are outputs also earlier to verify the rationality of the model. But be careful not to fall into the details of the code, the code details we can put into the subsequent coding process to refine. Start by modeling complex business case

Business modeling starts with complex business case, hits the core of the business field, catch.

In one aggregation, I usually choose to start with the "root entity", when modeling the root entity, it will gradually relate to other entity/value objects associated with it, and the business model is completed.

On the other hand, the practice shows that the business model involving case complexity from high to low in turn is: "Increase"--> "-->" delete "-->" check ", so my habit is to" increase "the business case completed, basically the business model is sorta, The next three case is simple, of course, there may be more than one case of "check", but much the same.

In a comprehensive view, aggregation in the "root entity" relative to other related entities/value objects, "increase" relative and "change" "Delete" "search" are more complex business case, complex to do, simple natural is done, so the proposal from the complex case to start modeling. replacing technical terms with business terms

This is the early stage of modeling, it is easy to go into the wrong, especially in the old code of the older system refactoring process, you will usually write code details, this time proposed to put aside the code, simply discuss the business model. Let everyone use the business model language to describe their problems and ideas. This is a difficult thing to do, but it needs to be adhered to and it will be found that people unconsciously use the model language to communicate. The "unified language" mentioned by Evans in the field-driven design book is consistent.