Domain model of field-driven design theory learning notes

2007 Eric Evans published "Domain driven design" so far, the concept of domain driven designs (Ddd:domain-driven design) has become increasingly understood and used. I have been a post-conscious, but it is not too late to mend. We are very familiar with the word domain, and often put it on the mouth, but how much value it? Developers are more focused on technology, and I actually want to study the DDD-based ASP. ASP. NET boilerplate. ABP is an open source framework, its layered framework, its code logic has a lot to learn, but if you want to really grasp it, I think it is to understand the theory, from the thought of making some changes, so-called Ax is this truth.
The core of domain-driven design is the domain model, first of all to build up a domain model with enough communication, then the domain model-driven software design, which is designed as a domain model in code ddd:domain-driven. How to communicate? Need a domain experts, software designers, developers can understand the common language, once UML seems to be a modeling language to achieve a smooth transition from analysis to design to coding, but in fact, there is still a gap in the analysis and design of UML, but also a strong professional.
Domain models are important and necessary, so what are the characteristics of domain models?
The domain model is an abstraction of a domain, a domain model that has boundaries, and a part of our focus in the field of model response. It's good to understand that the requirements of any one system have its boundaries, and the scope of project management is managing the boundaries of a project, which makes work manageable.
The domain model is not intended to conform to the "realistic" model as much as possible. Even modeling the real world is a simulation. Building a domain model is a reflection of the reality that is generalized for some purpose, similar to a film, presented to the audience in a special way, telling a story, and expounding a point of view.
The domain model reflects only the business, regardless of the technology implementation. For example, the field of human resources, supply chain and development technology implementation is irrelevant, but there are areas closely related to the development of technology, such as source code control system, software integration development environment. There are two ways of saying the difference between demand and design: the need is about what to do, the design is about what to do, and the other is: demand is about business, and design is about technology. From this perspective, a domain model is a work product that is used for demand analysis, or, indeed, for demand analysis.
The domain model is a condensed knowledge that ensures the business logic of the software in a model that facilitates business understanding. Domain models enable developers to smoothly translate domain knowledge into software implementations. In fact, most of the time developers are unfamiliar with the business domain and may not even understand it at all, requiring the developer to do the necessary business training before development. The domain model has been refined to communicate more efficiently. The key is also around the domain model, we can realize the component, improve the reuse, but also promote the software has better maintainability.
The domain model runs through the whole process of software requirement analysis, design and development, and becomes the core link of communication between all members of a team, and everyone is facing the same model. The old idea that the demand for personnel to develop requirements specifications, designers research requirements specifications to write design books, developers based on the design of the book to write code. Domain-driven design obviously does not recognize this approach, and developers need to be able to understand not only the domain model, but also the refinement and improvement of the domain model. This also means that the domain model runs through the entire life cycle of software development and is constantly being updated.
The domain model as a communication tool is visible and needs to be expressed. The most common use of this expression is the graph, but also the code or literal description. I am very curious about this, the diagram is very easy to understand, such as use case diagram, flowchart, code How to express the model and let the domain experts can understand? DDD establishes a common language, or pattern, of a domain called ubiquitous language.

Domain model of field-driven design theory learning notes