Talking about DDD field-driven design

Article Introduction

In the B-side product development and project implementation, what thinking does DDD bring to us? How do we apply? This article is not a popular science post, but aims to share our experiences and thoughts.

background

Domain Driven Design (DDD for short), also known as Domain Driven Design, originated from the book "DOMAIN-DRINEN DESIGN — TACKLING COMPLEXITY IN THE HEART OF SOFTWARE" published in 2003 by the outstanding software modeling expert Eric Evans (Chinese translation of "Domain-Driven Design" Design-The Way to Deal with the Core Complexity of Software"). With the publication of Martin Flower and James Lewis' "Microservice" in 2014, the concept of microservices has been accepted by the industry, and DDD has also been brought up again. It is found that the concepts of domain, bounded context, domain model in DDD are in a natural fit with the concept of high cohesion and low coupling of microservices. More and more people regard DDD as one of the methodologies to guide the division of microservices. More and more people believe that mastering DDD is an excellent architect.

DDD workflow-pictures from the Internet

Bounded Context-the picture comes from the Internet

Why should we start DDD?

The author’s team began to develop the company’s independent products around 2015. At that time, DDD was mainly used in our microservice division and code layering. It was important for us to build a unified microservice technical framework from a technical point of view. The guiding significance. The real start to think about applying DDD to specific business areas and business scenarios was at the end of 2018. At that time, we were faced with more and more projects implemented by independent products, and we needed to help customers build business applications from 0 to 1. How to find a suitable architecture solution in the complex business scenarios of the enterprise or even the industry was what we expected to use DDD to answer questions more systematically.

How do we apply DDD?

In the practice of DDD, most people should face a problem: too many nouns! Nouns such as "domain", "subdomain", "bounded context", "aggregation", "entity", "value object" and so on are dazzling. Moreover, although the theory of DDD tells us the definition and processing principles of nouns, it seems that there is no standard answer on how to analyze based on principles in specific scenarios.

This is also our biggest dilemma when applying DDD. We are also thinking repeatedly: how to unify the language within the team and how to integrate DDD principles into specific executable work items?

Next, we will share our experience and thinking from two aspects of people and things.

people:

The DDD emphasizes that domain experts and development teams work together.

domain expert joins, the essence of which is to return all design to the business itself, starting from business value, focusing on the core domain of the business, and avoiding over-design.

Hope that domain experts and development teams work together is often the first problem in practice. How to find qualified domain experts? How to guarantee the time investment of domain experts? How to maximize the "value" of domain experts?

• Regarding qualified domain experts: Domain experts do not refer to a specific person, they can be many people, and they can complement each other, but at the same time, too many are not recommended. When looking for domain experts, companies can start from their own business areas and find people with rich experience in each business area. The “experienced” here is not only rich front-line practical experience, but also a deep understanding and cognition of the business.
• Regarding the protection of domain experts' time investment: In practice, it will be found that there are various "objective" reasons that prevent domain experts from effectively investing. Although there are many objective situations, no matter how difficult it is, the time investment of experts in the protection field must be done. If domain experts are not involved, how can we be confident that we deliver business value rather than a bunch of code?
• How to maximize the "value" of domain experts: Concretize abstract problems, obtain more information from the domain experts of the enterprise through listening and guidance, and abandon the obsession of "I am an expert".

Development Team : In most informatization projects, the common division of labor is that requirements analysts collect and design requirements, technicians are responsible for development and implementation, and requirements analysts conduct test and acceptance. In the practice of DDD, it is recommended that the business architects, technical architects, and test architects of the development team work together from the beginning, so that they can play to the strengths of each role in their respective professional fields, gradually unify the language, and quickly reach a consensus.

thing:

DDD distinguishes two levels of strategic design and tactical design, and proposes three principles of focusing on core domains, creative collaboration, and unified language. When many people first started to apply DDD, they would feel that they "cannot speak" or "cannot do things". In fact, this is because we pay too much attention to the nouns themselves and get stuck in the understanding and interpretation of the nouns. Therefore, in terms of "things", we believe that we need to grasp two main points.

• Find a more comfortable way

DDD solves the problem of business boundary division through strategic design, and realizes the abstraction of domain model through tactical design, which solves the transition from business to technology.

When talking about DDD, event storms must not be avoided. "Event Storming is a fast design technique that allows domain experts and developers to participate in this fast-paced learning process. It focuses on business and business processes, rather than noun concepts and data." Excerpted from Vaughn Vernon's "Essence of Domain Driven Design"). Event storm provides a very logical and systematic method for the implementation of DDD strategy and tactics. Then, besides this method, are there other methods? The answer is yes. Especially in the information construction of B-end enterprises, many excellent methods and tools such as waterfall implementation methodology and agile development can be used by us.

During the implementation of DDD, our core is to grasp the final result to be obtained. The method adopted in the process can be adjusted according to the actual situation. The key is to find a way that makes most team members comfortable. Take the author’s experience as an example. A customer is used to business combing in the form of flowcharts. In this case, the use of event storms will have an impact on the customer’s habits and even make the customer wonder how to output. At this point, we should adjust in time and think about how to integrate the flow chart and the event storm, so as to not only advance in the way customers are used to, but also to get the results we want.

• principles and concepts into templates and specific tasks

A thousand people have a thousand Hamlet, and everyone has their own interpretation of the principles and concepts of DDD. In order to achieve the "unified language" of the DDD implementation method in the team more quickly, it is recommended to carry it with specific work tasks and output templates, so that the team can focus more on the achievement of goals and tasks.

By applying DDD in the R&D and implementation projects of our own products and continuing to iterate on its application methods, we not only effectively completed the implementation of the China-Taiwan project and built a reasonable application framework for customers, but also gradually improved the project implementation methodology system. More extensive project delivery and product development have provided assistance. DDD helps solve some of the problems in the product architecture design. After the architecture design, how to ensure the landing of the design and efficient delivery is the next problem that every team will face. Here, the author recommends the use of Zhufangyu, a digital intelligence performance platform, which can effectively manage the microservices or modules formed by the architecture design, pull through design and development, and improve the team by providing collaboration, testing, DevOps, and container tools. efficacy.

Pig tooth fish number intelligent performance platform

How do we understand DDD now?

DDD is first of all an idea, "focusing on the core domain, creative collaboration, and unified language", which is about value discovery, value identification, discussion, listening, consensus, and iteration. This kind of thinking applies not only to software design, but also to daily work, personal life, family education, and so on. We cannot be perfect in every aspect. We need to identify key tasks and focus on input; we cannot exist alone, we need to connect with others, listen in depth, and positive feedback; we are delighted in consensus and tacit understanding, and we have the courage to accept differences, because It is these differences that allow us to continue to collide, learn and grow better.

Secondly, DDD is a method that distinguishes between strategic design and tactical design, introduces bounded context and unified language, and provides entities, value objects, aggregations, factories, resource libraries, etc. At the same time, there are many DDD related works in the industry, which can help us understand these concepts and specific application methods more effectively. Of course, your own field and your past experience are also worthy of reference when applying these methods.

The software architecture is basically the mapping of the physical world in the digital world. In the application of DDD, we not only learn DDD ideas and methods, but also learn agile, DevOps, testing, microservices and other domain knowledge. At the same time, combined with our past experience, we have gradually summarized and iterated a set of architecture design systems and method. As Eric Evans said, "DDD is not over yet", we are also continuing to practice and continue to adjust.

This article is based on the author's current knowledge and understanding. Welcome to leave a message for discussion.

---

This article was originally created by the Toothfish technical team, please indicate the source for reprinting: official website

About

The Choerodon digital intelligence performance platform provides systematic methodology and collaboration, testing, DevOps and container tools to help companies pull through the requirements, design, development, deployment, testing and operation processes, and improve management efficiency and quality in one stop. From team collaboration to DevOps tool chain, from platform tools to systematic methodology, Pigtooth fully meets the requirements of collaborative management and engineering efficiency, runs through the entire end-to-end process, helps the team to be faster, stronger and more stable, and helps companies to promote digital intelligence Transformation and upgrading. here to try the pig tooth fish