preface

Some time ago, I shared an article about DDD and Ali Framework Cola learning and thinking: juejin.cn/post/705966…

I found that many students still have some questions about DDD after reading. Today, I will sort out an article for your questions, hoping to help you better understand DDD.

Don’t DDD for DDD’s sake

In fact, the idea of DDD has been put forward for many years, but there are still most companies do not use DDD to design projects. What kind of project should be refactoring DDD? I talk about some of their own understanding

1.1 Why DDD?

In fact, for us developers: everyone wants their code to be easy to understand, but after a long time of iteration, the code may become more and more complex as more features are added.

  • Unfriendly to new students: Complex code logic can be difficult for new students to understand.
  • Multi-team collaboration issues: The boundary of service system is not clear, and the dependency between systems is complex. Many students may have experienced a problem: a boundary problem of requirements, it may take an afternoon meeting to communicate With Raqi.So why different unified language domain modeling, so that technical students and business students can understand the same!
  • Lack of flexible expansion: for complex systems with frequent changes: how to achieve flexible expansion of scenes and architecture adjustment under complex systems?

In fact, all the above are problems existing in a complex business system, and I will simply list them

1.2 What are the benefits of DDD?

  • Business domain model oriented programming

Aggregate and precipitate systems with code: everyday business code does not do a better job of precipitating business knowledge because business knowledge exists everywhere, in util, models, services, and even configurations; This will lead to high maintenance costs of the code of their own systems. Business code is scattered all over the system, not well cohesive, low coupling.

  • Unified development and design ideas

DDD provides a unified design and development philosophy: the team will consciously form a unified language within the context of a bounded domain model to facilitate communication and reduce disagreement

  • Separation of concerns

Building domain model: Separate domain model from data model, business complexity from technical complexity, and keep the structure of system code clear to cope with expansion challenges.

1.3 Which system is suitable for DDD?

If a system has become very complex and maintenance costs are high, is it possible to consider refactoring DDD?

If some simple logic projects, such as some C-side projects in fact, the internal logic of the project is not very complex, more just read services, inter-system calls, then can not use DDD.

Of course, this is only my own point of view, specific problems or specific analysis.

2. Understand the core entry point of DDD

I see many students have questions and say:

Many students are worried that if students in a team have different understandings of the field, the code will still be confused in the long-term iteration process.

2.1 DDD core entry point

  • Common development philosophy and language

In view of the above problems, it is normal for different students to have different views on development, and their understanding of business is also different. However, unified team standards are a very important point in DDD development. Common language is the output of extracting domain knowledge. Obtaining unified language is the process of requirement analysis and understanding domain knowledge. In this process, the development students, the team TL, as well as the product manager, the domain architect, and so on are involved and come to a unified answer.

- For example, old students can help new students to get familiar with the business and the field model more quickly, so as to avoid mistakes in future development. - Analysis of a new demand: the team and the technical leader should first determine which field to develop, and then make specific technical segmentationCopy the code
  • field

The domain is at the heart of DDD design. How to determine the division of domain and construct domain model? Compartmentalize the domain with a good understanding of the business. Of course, in this series of transformations, we must not forget the purpose of transformation: to reduce business complexity and understanding. In the field division, it can also be subdivided: core field (transaction, order, etc.), general field (unified authority, without too much personalized appeal) and so on

  • Boundary context

This is also very important in the design of the domain. Simply put, the treatment of the anticorrosion layer should ensure the isolation between the business logic of the domain and the interaction between the domains. Handling the closing position is all that needs to be considered in boundary context.

2.2 Changes in design methods

Traditional system design may rely more on data-driven development. In DDD, however, the domain model is decoupled from the data model.

Therefore, in the transformation of DDD project, we must first change the original data-driven solidified idea, and first design the domain model is the most important.

This article is my own understanding. If you have any problems, please correct them and make progress together.