Shulou(Shulou.com)06/03 Report--

This article mainly introduces how to avoid over-design in DDD, which has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, let the editor take you to understand it.

DDD, that is, domain-driven design, is a modeling methodology, which emphasizes implementation through analysis, modeling and redesign, rather than database table-driven.

DDD deals with core complex business design, with special emphasis on "core" and "complexity". DDD is only applicable to business systems.

DDD simplifies the implementation of business systems, makes business logic highly cohesive, and aggregates are loosely coupled with domain events through aggregation root ID references. It is high cohesion and low coupling that keeps project code clean and tidy as business requirements continue to iterate.

Decoupling with infrastructure and framework is realized through four-tier architecture design / hexagonal architecture design.

DDD also solves the problem of splitting micro-services.

DDD solves business problems by identifying domain events, identifying boundary contexts, identifying problem subdomains, aggregating, and modeling aggregation through event storms. It is not to solve the problems of data query and data analysis.

Earlier, we learned how to solve the problem of separation of read and write through CQRS, however.

In the process of practical DDD, we always encounter some problems that are neither suitable for domain modeling nor simply solved by CQRS, such as how to implement the interface that provides options such as address and gender for the front end, how to design the user tag function, and how to design the evaluation function.

For these seemingly simple problems, what we need to consider is how to avoid overdesign and keep the architecture simple and extended.

There are many scenarios for providing options for the front end. Some options are enumerated types, such as gender, order type; some options need to support addition or deletion, such as item classification, although entities need to reference it through ID, they are not suitable for existence as entities.

Whether it is an option of an enumerated type or an option that is referenced by ID but not suitable for existence as an entity, it should be used as a value object. You can read and write storage / cache middleware directly in the application layer, such as mysql, es, redis.

The domain (business) nouns that will appear below: talent: Internet celebrities, celebrities, individuals with fan groups, individuals with certain influence; OTO store exploration: online registration and offline shopping, online promotion (mainly serving food spots, promoting offline stores for merchants)

We need to realize the need to label talented people in our project. When we receive this demand, the first thing we do is to analyze what kind of value the tag can produce, and then through the event storm to see if we can analyze the domain events.

Combined with the business analysis of the project, the value of the talent tag in our project is actually used for interest matching and push. In the OTO store exploration business scenario, interest matching can be understood as pushing relevant store orders to the talent according to the taste of the talent.

At the end of the analysis, we know that what the tag function needs to do is data analysis and algorithm recommendation. In addition, the tag does not have any domain events (behavior, business action), and the tag does not have a domain context, so it should not be overdesigned.

In addition, to label the talent / the talent themselves, then the label is the value object of the talent, and the gender, age, address and other attributes of the talent are the value object of the talent. Talent can add tags or delete tags.

So in the end, the tag function we achieve is to add a tag value object to the aggregation root of the talent. Add a method to modify the tag to the aggregation root of the talent.

In addition, we need to provide tag options for the frontend to allow administrators to add or delete tags. Just like implementing common options, we separately provide an application layer LableService under talent aggregation to directly operate the database to add / delete tags.

The existence of the label table only provides the option of tagging, and people who tag themselves can only choose from the tags provided by the system, and the label is equivalent to just an option. Therefore, the tag value object of the talent is not the id that stores the tag, but the name of the label directly.

When the tag option is deleted, we should not delete his tag by default for all users who have the tag, which is actually not allowed, just as we cannot casually change the user's gender and address.

Only when the talent updates the tag does not provide the deleted option, let the talent choose the new tag update, after the update, all the old tags are replaced to achieve the purpose of deletion.

In addition to options and labels, we also need to do an evaluation function.

According to the event storm, we analyze the events in the following areas: a, merchants can evaluate talent after completing the task (only once for each task) b, update the score of talent after business evaluation (such as content quality score). "talent" involves three dimensions: task, talent and businessman. Talent can check the comments given to them by merchants, and businesses can also check which reviews they have written to them. And can view the evaluation associated with the task.

Obviously, it is unreasonable to put the evaluation function into the task context, the talent context and the business context. Therefore, we divide the evaluation context for evaluation and identify the sub-domain of the evaluation problem. Business evaluation talent as an aggregation of evaluation context, later may also achieve support for talent evaluation store, and talent evaluation store is an aggregation of evaluation context, there are multiple aggregations in evaluation context.

In the process of actual combat DDD, we also do detailed analysis and redesign in the process of realizing front-end options, label function and evaluation function, in order to avoid over-design.

Thank you for reading this article carefully. I hope the article "how to avoid overdesign in DDD" shared by the editor will be helpful to everyone. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.