Overview of domain-driven models

ReadDomain-driven design tackling complexity in the heart of software

DddThe basic requirements for modeling are as follows,First, the model and implementation are mutually bound.In our current project, we may understand that, in general, we use a set of models to communicate with customers (which is easier for users to understand ), in our system implementation, our architecture is another model that is frequently used by our technicians;A language is generated based on the model.That is, the language that contains many domain terms and some technical terms. In the future model evolution and business discussions, you can use this language to organize sentences to describe the model;Model contains rich knowledgeBecause the model must solve complex domain problems, not just a data solution, the objects have behaviors and constraints.Model ExtractionWith the evolution and improvement of models, some important concepts have been added. Similarly, some concepts that are useless or cumbersome should be discarded, model is always the core of displaying the whole project in real time; ApplicationBrainstorm and perform simple experimentsCreate and extract models. The model-based language and the constraints in the implemented feedback loop provide support.

 

With regard to knowledge digestion, efficient domain modelers are knowledge digesters. They seek a simple view that is meaningful to a large amount of redundant information. As many models are abandoned after experiments, the significance of our work is that our achievements can accurately express the most relevant specific knowledge that has been found, that is, a group of abstract concepts that can clearly define the meaning of all details. This process is Ddd One obvious feature of this feature is that the development team cooperates with field experts and is led by developers to accept information and make it a useful form, the source of the raw materials can be the opinions of experts in the field, the existing system users, the technical team experience of the relevant old system, or another project in the same field, a large number of talks and documents. In the traditional waterfall mode, "business experts talk with analysts, analysts extract summaries, abstract the results, and then convey the results to developers who code the software ", this method fails because it does not have a feedback mechanism. Analysts only obtain information from business experts for work, they do not have the opportunity to learn new knowledge from developers or gain experience from early software versions, and the one-way flow of knowledge does not accumulate interaction. Projects that use the iteration process fail to effectively create new knowledge because they do not abstract the knowledge. Developers ask the business experts to describe the function and then build it, display the results, and ask for the next step, this is only effective when developers are familiar with this field. Even if useful software can be built, the project will never be able to derive more powerful new features from the early features. The simultaneous intervention of developers and analysts makes the model organized and abstract reasonably, and also provides great support for implementation. In addition, the expert in the field is involved in the process, the model reflects the deep business knowledge and can abstract real business rules. As a response model, the interaction between the model and programming and design should be a tool for information exchange in projects. The model is continuously evolving, but the model must be practical in the field, must be accurate to make the applicationProgramEasy to implement and understand.

 

For the project documentation,"CodeIs the document ",XPIt has been promoted for a long time, but it is also limited. written documents, diagrams, and code should be complementary to each other. The key scenarios are small and accurate.UMLA graph is necessary. A model is not a graph. A graph and a document are used to supplement the concept of a model beyond the code. Both the code and the document should use the language of the model.

 

our current practice will always make you feel the shadows of both the old method and the new process, after all, there will always be a variety of practical projects The existence of objective factors, resources, risks, and so on. Learning these new and promoted practices allows you to participate in the practice from another height or perspective. No matter what process you use, good practices can always be used for reference.