Shulou(Shulou.com)06/03 Report--

Easy to learn one of DDD: model-driven Design

I first came into contact with DDD (Domain driven Design) in 2012. I have read Eric's masterpiece "Domain driven Design: how to deal with Software Core complexity" several times, and have also used DDD to ReFactor a project. The general feeling is that some concepts of DDD are obscure and difficult to grasp, so I want to write a series of essays, hoping to help you understand DDD more easily and deeply in an easy-to-understand language. Many of the articles are my personal experience and understanding, there will inevitably be mistakes, I hope you can correct them in time and improve them together.

This article, the first in a series of short articles, introduces the initial conceptual model-driven design of DDD.

1. Review of software development methods

Software development can be seen as a process of transforming user requirements into programs that can run correctly, and the most important part is to convert user requirements into code. The DDD we want to learn is actually a software development method, which can better deal with the core complexity of the software than the previous software development method. In order to better understand it, let's review the previous software development methods and their problems.

In the 1960s, due to the simple requirements, software development was dominated by workshop development. However, with the rapid development of hardware, the complexity of software also surged rapidly, which finally triggered the software crisis in 1970. In order to deal with the crisis, the industry draws lessons from the mature manufacturing management methods and develops a "process-centered" waterfall development method.

1.1 Waterfall development

Waterfall development divides the whole software development process into requirements analysis, scheme design, coding, testing and other stages, hoping to use this similar industrial assembly line to control the risk and cost of software development.

Requirements analysis: through requirements analysis, we need to clarify the functions that users want, how to use these functions, and what value can be obtained through these functions; eliminate ambiguity and contradictions in user requirements; refine a variety of normal / abnormal function scenarios, acceptance criteria, performance, reliability and other non-functional constraints. Design: in the design stage, the overall implementation scheme of the software needs to be determined according to the results of requirement analysis. In the system design stage, the subsystem division will be determined, and the development, operation platform, database and other key technologies will be selected; in the scheme design stage, the module division, module internal architecture, collaboration process, key algorithms and so on will be clearly defined. Coding: complete the code according to the design. Test: test whether the software meets the needs of users.

The above figure shows the software development process using the waterfall development method. We can see that this method can decompose complexity and improve efficiency through professional division of labor and pipelining, which alleviates the software crisis in a certain program. However, different from industrial production, there are many uncertain factors in software requirements and development process, so this method also finds a lot of problems in the application process. Each stage of each requirement is completed by different people in turn, knowledge is transferred by documents between stages, lack of communication and feedback between stages, errors and understanding deviations can not be corrected in time, which often affect the correct delivery of the software. Each requirement outputs its own analysis and design documents without integration. With the growth of software scale, analysis and design will lose the grasp of software integrity, and then affect the comprehensiveness and correctness of analysis and design. Due to the lack of feedback, the differences between analysis, design and code will become greater and greater, the analysis and design documents that cost a lot of manpower will gradually lose their value, collaboration will become more and more difficult, and the software will become more and more difficult to deliver correctly on schedule.

In order to solve the problems of low development efficiency and slow response speed of waterfall development, lightweight and more adaptable agile software development methods have been widely recognized and rapidly popular, extreme programming is one of them.

2 extreme programming

XP is mainly composed of 13 practices and is a near-spiral development method. It divides the complex development process into relatively simple small cycles; through positive communication, feedback and a series of other methods, developers and customers can be very clear about the development progress, changes, problems to be solved and potential difficulties, and adjust the development process in time according to the actual situation.

To compare with waterfall development, we simply understand XP as the following figure:

As we can see from the figure above, XP does not divide the analysis, design, coding, and testing phases, and requirements can be delivered quickly in an iteration with a cycle of 1 to 2 weeks. There are several reasons why XP can deliver quickly:

Customers, business experts, developers and testers sit together to complete requirements development, and face-to-face communication replaces documents, saving the workload of document writing and maintenance. Through simple design, TDD, ATDD, CI and other engineering practices to ensure faster feedback and full parallelism between analysis, design, coding and testing, and effectively shorten the development cycle. By constantly refactoring the code to ensure that the code is more concise, can better reflect the core complexity of the software. The sharing of skills and knowledge is promoted through pairing, code collective ownership, system metaphors, coding specifications, and complete teams.

XP is very opposed to pre-design, requirements analysis and design will be split into user stories and even small iterations of TDD to do, in each small iteration the code will only be simply implemented according to the current requirements; when the code is found to be difficult to meet new requirements in subsequent iterations, it is necessary to increase the adaptability of the code to new requirements through refactoring, so that new requirements can be realized quickly. This approach can bring a lot of benefits, but it also has some disadvantages:

If the complexity of the software is high and there is a complex relationship between the requirements, the developer rashly starts to write code without a good understanding of the business logic, which will bring great refactoring costs and even need to be rewritten. Only the code carries the business consensus, and the cost of maintaining the business consensus is high, which ultimately makes it difficult to maintain the business consensus. The consensus of communication exists not only in the mind, but only in the code, which puts forward very high requirements for the business expression of the code and the code understanding ability of experts / customers. in the end, it may lead to more and more differences in people's understanding of the business. 3. Model driven design

In order to make up for the deficiency of XP in dealing with software core complexity, eric put forward a new method in 2003. He thinks that we need to introduce domain model and do requirement analysis and software design around it, which is called model-driven development. This discussion has the following main points:

The model is unified, and it reflects the core complexity of the domain, rather than the details of every requirement in the domain. Some details that do not involve the core value of the software and do not affect the overall situation can be considered in the iteration, and the relevant knowledge can be deposited in the code, just as XP does; but the business logic that involves the core value of the software, or the business logic that affects the whole world, needs to be integrated into the domain model for unified and detailed analysis, and constantly evolves and refines in the software life cycle. The model is the center of communication and collaboration. Customers, business experts, developers, testing and other roles participate in building the model together, and we communicate and collaborate based on the common model. The model is bound to the code. Code modification can be easily synchronized to the model, and model modification can also easily synchronize the code. This requires the model to reflect not only the knowledge and constraints of the problem domain, but also the knowledge and constraints of the implementation domain; the code involving business logic needs to be constantly refined and stripped of the technical implementation details in order to express the model well.

Finally, through the unified modeling of software core complexity, model-driven design solves the defects of waterfall development in requirement analysis, software design communication, feedback and knowledge integration, as well as the defects of XP minimalist design.

The text focuses on why we need a domain model and several basic principles that should be paid attention to in the construction of a domain model, but how to build a domain model? Please see the next article, "easy to learn DD II: how to digest knowledge efficiently".

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.