This book is Eric Evans's own dictionary-style reference to Domain-Driven Design - Coping with Complexity at the Core of Software, which can be used to quickly find many of the concepts in Domain-Driven Design and their concise explanations.
Other addresses of other articles in this series:
[Translation] Domain Driven Design Reference (1) - Preface
I. Make the model work
Domain Driven Design is an approach to developing complex software:
1. Focus on core areas.
2. Explore the creative collaboration model of domain practitioners and software practitioners.
3. Speak common language within a clearly bounded context.
The three-point summary of DDD is defined in terms of terms defined in this manual.
Many projects do modeling work without getting much real benefit in the end. The DDD pattern distills successful practices from a project so that modeling brings enormous benefits. In general, they propose a completely different approach to modeling and software development than the detail-to-high-level perspective [ 1, before DDD we were mostly used to designing datasheets first ]. Rigorous modeling conventions must balance model exploration in collaboration with non-technical people [ 2, generally domain experts in this case]. Tactics and strategy must be combined to be successful, and DDD involves the design of both tactics and strategy.
bounded context
Any large project has multiple models. They appear for many reasons. The two subsystems typically serve very different groups of users and have different jobs, where building different models may be useful. Teams working independently due to lack of communication may have solved the same problem in different ways. Toolsets may also differ, which means that program code cannot be shared.
Multiple models are inevitable, and when code based on different models is merged, the software becomes buggy, unreliable, and difficult to understand. Communication among team members became confused. It is often unclear under what circumstances a model should not be used.
Model expressions, like any other phrase, have meaning only in context.
therefore:
Clearly define the context in which the model applies. Clearly set boundaries based on team organization, usage of specific parts of the application, and physical representations such as codebases and database schemas. Applying "continuous integration" keeps model concepts and terminology strictly consistent within these boundaries, but not distracted or confused by external issues. Standardize a single development process in the context that does not need to be used elsewhere.
common language
First write a sentence,
Then break it into small pieces,
Shuffle and reorder them again.
as if by coincidence,
The order of the phrases has absolutely no bearing on the meaning.
--Lewis Carroll, "Poetry Becomes Not Born"
Creating a flexible, knowledge-rich design requires a common, shared team language that should be tested at all times, which unfortunately rarely occurs on software projects.
Within a single bounded context, the language may be broken in some way, undermining efforts to apply complex modeling. If the model is only used to draw UML diagrams for the technical staff of the team, it does nothing to contribute to the creative collaboration at the heart of DDD.
Domain experts use their terminology, while technical team members have their own language to discuss the field from a design perspective. Terms that are discussed on a daily basis vs. terms that are embedded in the code (ultimately the most important product of a software project). Even the same person speaks and writes in different languages, making the sharpest expressions in the field often in ephemeral forms that are never captured in code or even in writing.
Translation can lead to poor communication and a lack of knowledge.
However, none of these languages can be a common language because none serves all needs.
Domain experts should object to terminology or constructs that are awkward or insufficient to convey domain understanding; developers should be aware that ambiguity or inconsistency will hinder design.
When talking about the system, bring the model. Use the elements and interactions of the model to describe the scene aloud, combining concepts in a way that the model allows. Find easier ways to say what you need to say, and bring those new ideas back into diagrams and code. With the popularity of the language, a model is more than just a design. It becomes an indispensable thing for developers and domain experts to accomplish together.
therefore:
Use models as the backbone of the language. Make sure the team uses the language relentlessly in all communications within the team and in the code. In a bounded context, use the same language in diagrams, writing, and especially communication.
Realize that a change in speech is a change in the model.
Difficulties are addressed by experimenting with alternative expressions to embody alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve terminology confusion in conversations just as we agree on the meaning of common words.
Continuous Integration
Once a bounded context is defined, we must keep it healthy.
Model fragmentation is a strong trend when many people are working in the same bounded context. The bigger the team, the bigger the problem, but only three or four people will have serious problems. However, breaking down the system into smaller contexts ultimately loses an integrated and cohesive value.
therefore:
Often work on a process of merging all code and other implementation artifacts, with automated tests to quickly flag fragments. Relentlessly using a common language, as concepts evolve in different people's minds, a common view of the model is gradually formed.
Model Driven Design
Tightly tying the code to the underlying model gives the code meaning and makes the model relevant.
If the design or its central parts are not mapped to the domain model, the model is of little value and the correctness of the software is questionable. At the same time, the complex mapping between models and design functions is incomprehensible and practically impossible to maintain as the design changes. Establish a red line between analysis and design so that the insights gained in each such activity do not affect the other.
Extract the basic assignment of terms and responsibilities used in the design from the model. The code becomes an expression of the model, so changes to the code are changes to the model. Its impact therefore necessarily involves the rest of the project's activities.
therefore:
Design a part of a software system that reflects the domain model in a very intuitive way so that the mapping is obvious. Revisit the model and modify it to implement it more naturally in software, even if you try to make it more deeply reflect the domain. A single model is needed that, in addition to supporting a fluent common language, serves the right purpose.
hands-on modeler
A model has nothing to do with software if the person writing the code is not responsible for the model, or doesn't know how to make the model work for the application. If the developers don't realize that changing the code will change the model, their refactoring will weaken the model instead of strengthening it. At the same time, a sense of implementation constraints is never gained or quickly lost when the modeler is separated from the implementation process. The fundamental constraint of Model-Driven Design is that the model supports an efficient implementation and abstracts key insights into the domain, and halfway through, the resulting model will be unrealistic. Finally, if the division of labor prevents this collaboration, the knowledge and skills of experienced designers do not transfer to other developers, conveying the subtleties of model-driven design coding.
therefore:
Any technical person who contributes to the model must spend some time touching the code, no matter what major role he plays in the project. Anyone responsible for changing the code must learn to express the model in code. Every developer must participate in some discussions about the model and connect with domain experts. Those who contribute in different ways must intentionally hire those who touch the code in a dynamic exchange of model ideas through a common language.
Refactoring Deep Insights
Using a proven set of basic building blocks and a consistent language brings some clarity to the development effort. This avoids the challenge of actually finding a sharp model, one that captures the subtle concerns of domain experts and can drive a tangible design. A model under the superficial surface captures the essence of a deep model. This should make the software more in line with the mindset of domain experts and more in line with the needs of users.
Traditionally, refactoring is a term used to describe technically motivated code transformations. Refactoring can also be motivated by insights into the domain and corresponding improvements to the model or its representation in the code.
Complex domain models are rarely useful unless they are developed through an iterative process of refactoring, including the close participation of domain experts and developers interested in learning about the domain.
Author: Zachary_Fan
Source: http://www.cnblogs.com/Zachary-Fan/p/DDDReference2.html
If you want to get the news push of personal self-written articles in time, please scan the QR code below~.
