Conclusion - The So-Called Experts Are Those Who Have Crossed the Trench and the Ocean #
Hello, I am Ou Chuangxin.
This is the last lecture of this column. I would like to thank you for your companionship over the past two months and for your opinions and suggestions. Including the preparation phase, it has been about half a year since the beginning of this column. During this half year, I have also been on a journey of self-improvement. Through this column, I have organized my previously unorganized experiences, methods, and design ideas into a systematic theory and knowledge base for middle-end and microservice design.
In writing this column, I have taken the perspective of an architect and tried to present my experiences, thoughts, and insights from my practical experience, as well as original examples, to you in a comprehensive and detailed manner. I hope that this column can be helpful to your DDD practice and architectural design, and I also hope that you can quickly grow into an architect and DDD design master with an enterprise-level strategic perspective.
Speaking of growth, I believe that each person’s journey is unique, but there is one thing that you must have experienced the same as me. That is “the so-called master is someone who crosses the pitfalls and the sea!” Every step is accumulation, every step is experience, every step counts! So, at the end of this column, I still want to share some practical knowledge with you, as well as some pitfalls that I have encountered.
Many people come into contact with DDD, starting with tactical design, and may not know how to start practicing DDD. With this column, we can start with domain modeling. With a domain model, we can identify logical and physical boundaries of microservices; it is also because of the domain model that we can identify key objects within microservices and establish their dependencies, and then start the design and development of microservices.
Most books on DDD and microservice design focus on discussing tactical design or some general microservice design patterns. These books mostly do not tell us how to start building a domain model from a business domain. They do not explain how to use DDD principles to guide the design of middle-end and microservices. They do not explain how to use the domain model as input to design and break down microservices. They do not explain how to combine the knowledge system of DDD and apply it to the design and development of middle-end and microservices…
This is also the difference between this column and those books. Of course, I am not saying that those books are not good, they just have different focuses. When it comes to actual practice, a strong knowledge foundation is essential. You can combine this column with books to maximize your learning effectiveness.
Below are a few books that I recommend. They complement this column, and if you are interested in further learning about DDD, they are excellent learning materials.
DDD is a relatively complex methodology, and it has certain differences from traditional software development models or processes. When practicing DDD, you may encounter some difficulties. The enterprise needs to make adjustments in the development mode, and the project team also needs to improve their DDD design and technical capabilities and cultivate an environment that is conducive to DDD growth. Looking at it from a higher perspective, I think you may encounter these three major pitfalls, and I will discuss my views on them below.
1. Questions from Business Experts or Domain Experts #
In traditional enterprises, business personnel are the main proposers of requirements, but due to departmental barriers, they rarely participate in the software design and development process. If the development model is not adjusted, don’t expect business personnel to actively join the project team and participate in domain modeling. Does the lack of involvement from business personnel mean that there are no domain experts and domain modeling cannot be done? Actually, it’s not like that.
For mature business domain modeling, we can select individuals from the team of requirements personnel or experienced designers or developers who have a deep understanding of the business implications and business management requirements to serve as domain experts and complete the domain modeling. For project personnel who are familiar with both business and object-oriented design, this design experience is particularly important. They can use their experience in object-oriented design to better understand and identify the domain objects and business behaviors of the domain model, which helps to promote the design of the domain model.
As for new startups, they are facing completely new business and domains that no one has ever done before, let alone domain experts. In this case, the team needs to go through more detailed event storms together to establish the domain model. Of course, the modeling process cannot be separated from the analysis of the product vision. This process determines and unifies the system construction goals and identifies the core competitiveness of the project. The domain model of such startup businesses often needs to go through multiple iterations before it can take shape. Don’t expect to establish a perfect domain model in just one try.
2. Issues with the Concept and Technical Abilities of the DDD Team #
After completing the domain modeling and microservice design, it is time to start development and testing. At this point, you may find that some developers do not understand the DDD design methodology, and they are unfamiliar with concepts such as aggregates, layers, and boundaries. They may also not know about service dependencies and the responsibilities between layers.
This can lead to a situation where the design is sophisticated, but the development is poor. To address this, besides educating the project team about DDD knowledge and design concepts, it is important to involve all project members in the domain modeling process as early as possible. Conducting event storming sessions not only helps establish a common team language but also allows team members to familiarize themselves with the domain model, design essentials, and important considerations in advance.
3. Issues with DDD Design Principles #
DDD is based on various considerations and has many design principles, as well as the use of many design patterns. With so many rules and regulations, many people may feel restricted and constantly worry or hesitate whether they are following the authentic DDD. In fact, we don’t need to pursue the extreme of DDD, as doing so will lead to overdesign, increasing development complexity and project costs.
The design principles and patterns of DDD consider many specific scenarios or prerequisites. Some are for decoupling, such as repository services, boundaries, and layers, while others are for ensuring data consistency, such as aggregate root management. After understanding the fundamental reasons behind these design principles, in certain situations, you can flexibly grasp the design methods. You can break some principles and not be limited by rigid regulations, boldly choosing the most suitable approach.
These are my understandings of these three questions.
The key to using DDD well is to first comprehend the core design thoughts and concepts of DDD, understand why it is suitable for microservices architecture, and then slowly gain insights, digest, absorb, and practice. Although the DDD system is complex, it also follows a set of rules. By following examples and conducting several event storms, completing domain modeling and microservice design, and experiencing the entire design process of DDD, I believe you will soon understand the core design concepts of DDD. This way, you can freely navigate and pave your own path in DDD practices.
Well, it’s time to say goodbye. Thank you again for your companionship, and I look forward to meeting again! May we all be able to overcome obstacles and conquer new horizons!