Domain Driven Design series: clarifying some basic concepts

To study ddd, it is important to recognize that the core of DDD is universal language and model-driven design. Even Dddlite (technical ddd) must be aware of the location of DDD in the architecture and the necessary architectural knowledge, otherwise it is unknown whether to go all the way back. We first understand the common architecture layering, then understand the level and scope of DDD, and then emphasize the core of DDD. This includes decision making from architecture to domain model design and a little bit of your own practice.

1. Layer three as the basis: the presentation layer, the business logic layer, and the data access layer are the basis for all discussions. There are 2 of the most important decisions and practices awaiting your application and discovery:

(1) Based on the assumption that there are multiple presentation tiers , you can detach the business logic code that is scattered in the presentation layer.

(2) on the assumption that you need to support different kinds of data sources , you can isolate the data access layer code that is scattered across the business logic layer.

This means that most of the time you don't have to contemplate and racking to figure out what the three story is, and if you read a lot of books, you can see these principles in the book, and if you write more and more about the custom refactoring you will naturally find these principles. It is most important to discover and apply these principles in refactoring, and it is impossible to make sense of the "effort too little, too much thought" way.

2. Layer Four as the core: separating the business logic layer into the application layer and the domain layer is the core of the architecture of the domain-driven design. There are also 2 of the most important decisions and practices to keep the domain layer pure:

(1) Separate the business logic calls that the presentation layer must have to the application layer in a way that applies the interface. Other parts that do not need to be exposed are detached to the domain logic layer.

(2) Translating the business logic's reliance on specific technologies into interface dependencies, separating the definition and invocation of the interface into the application layer.

This means that even if the domain model is not taken into account, we can generally clarify the application layer and the domain layer. You need to do it, just look at it. Most of the problems are not in practice, and most of the problems are not actually there, you will summarize these practices, but your code will not completely reflect these principles, because this is in itself a decision at the architectural level, and no framework or presentation can perfectly reflect the things that make up the decision on the architecture. There is absolutely no way to "look at the code" to figure this out.

3. Organizational Forms of domain models: entities, value objects, and Domain Services are just one form of the domain model . 2 points must be noted:

(1) The organizational form of domain model is the category of domain layer.

(2) whether to adopt the classical DDD Domain Model organization mode has no effect on the architecture hierarchy.

This is finally the domain-driven design-related concept, which has been discussed in terms of architecture, which can be said to be irrelevant to the domain-driven. What is the core of domain-driven design? Design is a process, and domain-driven is a principle. Design under the principle of domain-driven design, the result is a series of models mainly in the domain layer category. If you do not summarize, you can go to see the classic DDD Appendix field driver Design diagram of the two core: common language and model-driven design. So talking about DDD has to be a combination of specific domain logic and various decisions and outcomes in the design, and even dddlite (technical ddd) should not be considered domain-driven because of the many architectural concepts involved in domain-driven design. At least you should be aware of the architecture independence of DDD.

4. Results of the domain model:

(1) The result of modeling is determined by the domain logic, and the result consists of one or more models of one or more types (entities, value objects, and Domain Services).

(2) If the domain logic is just a simple computational process, then the model may just be a domain service that contains a method.

(3) If the domain logic is biased towards data management, the model may consist mainly of a series of related entities, which are formally consistent with the anemia model.

Because most of the application's domain logic is relatively simple, biased process and data manipulation, so the domain model is not rich enough, but this is the domain logic natural analysis results. In constant refactoring, entity and Domain Services gradually separate the domain logic code in the application layer.

5. Entities:

(1) If the business logic is more suitable for the process expression, the entity does not need to exist.

(2) The entity corresponds to the concept of collections and types, and multiple objects of the same entity are unique. So the forum area (plates, themes, reviews) and e-commerce (classifications, products, orders) are all natural entity types.

6. Value object:

(1) If the entity is relatively simple, the value object does not need to exist.

(2) The concept of value objects for enumerations and states. A value object is part of an entity property. These value objects are inherently free of any difference. So the Forum area (subject state) and the e-commerce field (type of transaction, order status) are all natural value objects.

7. Domain Services:

(1) If the entity's method can be modified to a static method, then this method is more suitable to be placed in the domain service.

(2) If I only unit test the domain layer, I must repeatedly write some code that appears in the application layer to coordinate the domain logic, then the code is likely to belong to the domain service.

8. Summary:

(1) Before applying ddd, at least be able to understand the three layers correctly. If this is not possible, it is impossible to successfully apply it. In general the code does not know where to write, but also talk about what separation field.

(2) In the early stage must be in the framework and modeling aspects as far as possible in the hierarchy and clear concept, the latter side of the reconstruction side of the added function than not refactoring to add more features faster, the most feared is not to know and not to have a solution.

(3) It is not necessary to master all DDD knowledge and concepts in order to apply DDD. The core of DDD is the common language and model-driven design.

(4) DDD is a process in which the most appropriate design and code is obtained in an ongoing refactoring process, so do not ddd for DDD.

The following ASP is recommended by the way . NET Design Patterns This book, the book and some of the authors ' previous books and their source code is the source of the so-called various frameworks and original articles and published books of the 99% major blog forums of the year. The success of the author is similar to the method of popular science to let everyone put the pattern and code directly to everyone, the failure is the domestic perpetual plagiarism style still did not let this book, a lot of two times to process a variety of articles, posts, discussions and books. But this is not the failure of the author and his works, but the sorrow of those of us who are the copycats of our original hats. Architectural knowledge, in itself must have a number of project experience of the practice to have practical advantages and disadvantages of understanding and cognition, DDD is a complex business logic must have a gradual restructuring experience to accumulate and experience. If we want to make progress, we can not do without thinking and reconstructing. In the atmosphere of this technical community in the country, practice class is not respected, pseudo-technical text (title Party + Picture Party + program Life Party) and pseudo-original (plagiarism foreign books, blog deliberately declared as original) Big line of its way, if you read for several years blog feel not to see useful articles, or operability is not strong or can not be refined, calm down to the heart, Start subscribing to useful blogs (I'm interested in blogs that suggest you look), start reading foreign technical books and blogs, start refactoring your code, and harvest will accumulate over the world.

Domain Driven Design series: clarifying some basic concepts