Domain-driven design: Understanding ddd

No matter whether there is software support or software is good or bad, hundreds of millions occur in every field around the world every day.UnderstandableBusiness

Domain-driven design is a design method. It is hard to understand and evolve the software to solve the problem. The method used is to build a model around the business concept.

However, you can also understand the domain-driven design from two perspectives: DDD as the design result and DDD as the development method, that is, what and how.

The domain-driven design as a result is such a design (what): it buildsModelThis model has the following features:

• It is described in ubiquitous language and can be used for communication between business experts and development teams who do not necessarily understand programming, communication within the development team, and the names of classes and methods in the code.

• It includes some basic concepts in the business field, as well as the relationship between concepts, how they work together to complete various daily work in the business field. these concepts have nothing to do with software. Whether you use software to model them, they appear in the minds of practitioners every day, in conversations, in company books. in other words, it reflects the knowledge in this field. anyone who understands this model understands how this field works.

• It is rarely a big and comprehensive model, because the same thing has different concepts, terms, and roles in different business scenarios. the same data has different meanings and interpretations in different scenarios. therefore, concepts in the model are naturally grouped by application scenarios. Their associations with concepts in other scenarios are maintained through an internal ing.

• It is a descriptive model with no implementation details because it separates the technical complexity of the software itself and focuses on describing the business field. in this way, the complexity of the model is determined only by the complexity of the business field. the general result is that this will make it simpler.

Such a model is easy to change with business changes. At least it should not be more difficult or drastic than the changes in the business itself. conservatively speaking, the changes in the business field are much slower than those in the technical field. The model reflects the business and therefore is more stable. when the service changes, the model only needs to be adjusted. the business is actually not complicated. No matter whether there is software support, every field actually goes through hundreds of millions of projects every day, which can be traced from the financial point of view, and can be understood from the perspective of practitioners, business that managers can control. the reason why software cannot be correctly expressed lies not in the complexity of the business, but in the tools and methods we use. ddd tries to separate the complexity of implementation (solution domain), restore the simplicity of the business (problem domain), and provides corresponding tools and method support.

 

The prospect of this model is exciting, but how can it be achieved )? We need technical support and development process practice support.

The book describes some general building blocks, that is, technical support:

• Entity, value object and aggregate

• Repository and factory

• Layered Architecture, module and service etc.

• Side-effect-free-Function

• Intention-revealing-interface, specification and assertion etc.

• ...

Of course, these construction blocks are not all. New models will be constantly developed to bridge the gap between analysis, design, and implementation.These construction blocks are not required either.. Although Eric said in the book that the design must be implemented, the implementation does not have to be the constructed block provided in the book, such as entity, value object, and repository. likewise, if entity, value object, and repository are used, it does not necessarily mean that you are performing DDD. in fact, similar to the basic concepts of entity and value object, side effect free function is a common sense that any design and any design method should be considered.

 

More importantly, which practices can support the implementation of DDD in the development process? In fact, this part is the core of DDD, and you can even understand it as what rather than how. therefore, the description can be reversed: we cannot guarantee a perfect domain model. We can only try our best to improve the model at hand during the development process, and then let it go. thereforeHow to improve the model is the key, DDD provides some basic methods to facilitate this improvement.

• Cooperation between the development team and experts in the field: Brainstorming, sketch, continuous learning, and knowledge digestion...

• Model as a unified language: capture language inconsistency; improve the model through dialogue.

• Binding models and design implementation: Eliminate gaps between analysis and design. Modeling personnel are also responsible for implementing

• Transform implicit concepts into explicit concepts: Listen to expressions, check for inconsistencies, study contradictions, read books, and constantly rebuild

• Leveraging the Analysis Model

• The design model, especially the strategy model, focuses on the model concept rather than the implementation model.

• Deeper reconstruction: Build an exploration team, seize the opportunity of mismatch between each model and reality, and regard crisis as an opportunity.

• ...

 

However, we usually face more practical constraints. For example, we do not have to build a new system from the beginning every time, we have to integrate with legacy systems, or we only have one development team, we need to work with other teams. eric calls the solution to this problemStrategic Design(Strategic Design)

• The system is widely used and has a large scale: bounded context, context map, system metaphor, responsibility layers, and knowledge level.

• Multiple teams develop in parallel and need to interact with each other: Shared kernel, customer/supplier team, conformist, anticorruption Layer

• There are other systems (usually legacy systems) that need to be integrated: anti‑uption layer, each going through its own path, open host service, published language

• Limited resources, unlimited problems: good steel on the cutting edge, distill core domain

This is indeed the most difficult part. If an inappropriate direction is selected in strategy, the domain model can only be regarded as partial optimization for the previous construction block. taowen said that only the fourth part of the book "DDD" can be read. This is also a type of distill core domain.