Domain Driven Design - MDD

I. MDD

In domain-driven design, the most important thing is Model Driven Development, model-driven development (MDD).There is a famous saying in the programming world "rely on the abstract rather than on the concrete".This is both a principle of design and a process in MDD.The model is abstracted from the specific business through thinking.
In the early software development, there are generally clear and specific requirements, and the industry is relatively fixed.Such software does not have high design requirements or the design cannot play an important role in it.As the saying goes, "kill a chicken with a butcher's knife".But this does not mean that design is not important. As the complexity and scale of software businesses continue to grow, the importance of software design is increasingly reflected.
In this process, the fixed mode and the work that is relatively easy to separate from the actual business are more conducive to the rapid introduction of the design, and the actual situation is also the same.But the complex business and the parts that are inextricably linked to the business are difficult to abstractly design.However, it does not mean that it is impossible. Domain design is the way to solve this practical scenario, and whether it is possible to abstract the actual energy into a model, which can drive the development of the entire business logic.A good model can not only have better business flexibility and scalability, but also can be jointly improved by different application personnel with the help of a common language, and finally guide software coding to realize business functions.
A key point here is that in the previous model design, the model is the model, and the program design is the design, and the two are basically separated, but in MDD, the boundaries between the two are blurred, or theThe two should be organically unified.That's the point, a model, used synchronously.
When it comes to MDD, we have to mention MDA, MDA, Model Driven Architecture, Model Driven Architecture, which was proposed by the International Object Management Group (OMG, Object Management Group) in July 2001 based on the formalization of MDDmodel-driven architecture.The so-called driver architecture is actually the separation of models and technologies to achieve portability, interoperability and reusability.Due to the decoupling of the business code, it can better adapt to the expansion and adaptability of the two levels.Iterative development of technology and changes in business have no impact on each other.
The description of MDD can use some familiar modeling standards (UML, MOF, XMI, etc.) to achieve readability.
With MDD, there will be MDF, that is, MDD Framework, a model-driven development framework. After all, it is meaningless to build something from scratch and constantly recreate some wheels.At the same time, it can occupy the market, make high-profile money, and serve multiple purposes with one stone. It is the best to engage in frameworks.There is no description of the MDF framework here, and the focus is on MDD.

Second, the core of MDD

What is the core of MDD?The consistency between the model and the design must be strictly guaranteed within a controllable range.As mentioned earlier, MDD is to ensure the adaptability of the model. It cannot be like pure model design. In the actual development stage, the model basically has no effect.MDD maintains the availability of the entire model throughout the programming development cycle.It is necessary to use some development tools and auxiliary means on this basis.For example, the requirements for some paradigms and the matching degree of tools.
As long as a practical model is designed, software development is actually a unified iterative process of continuously refining the model, design and code.

Three, MDD driver process

First of all, it is necessary to understand some professional terms of MDD: domain, bounded context, association, entity, value object, domain service, etc.These will be explained in detail later, here we will focus on the driving process:
1. Deriving the preliminary domain and bounded context (module) from the actual business scenario, as well as the relationship between the contexts;
2. Analyzing the context and dividingEntities and value objects;
3. Associate aggregate entities and value objects to obtain aggregate categories and aggregate roots;
4. Design repository (repository) from aggregate roots, and design how to create entities and value objects;
5. Apply the model and constantly reconstruct the model in practice.

Four. Summary

To learn any kind of knowledge, you must grasp the main part and follow the outline.Enter the space without gaps.Domain design, first of all to do a good job of MDD, the ability of abstract model is the ability of your domain design.To have the ability to have a good abstract model, in addition to being sensitive to the domain division (that is, the boundary) of the business itself, have a good domain idea, be familiar with the means and methods of model creation, and have a deep grasp of technology applications.To create a good domain model.
Learn more, apply more, think more, and improve the level of thinking.