00 Introductory Words Let’s truly implement DDD ideas #

Hello, I’m Fan Gang, former Chief Architect of Aerospace Information and author of the book “Big Refactoring”.

As a practitioner and advocate of internet and big data transformation, I have participated in dozens of large-scale software projects in various fields such as national finance, military-industrial, taxation, and healthcare. I have been involved in major projects such as legacy system transformation and system refactoring multiple times, and have rich practical experience in system optimization and transformation. At the same time, in the past decade, I have provided training and consulting services on architecture design, software refactoring, microservices, and big data to numerous well-known companies including Bank of China, People’s Bank of China, Huawei, ZTE, Bell/Nokia, Siemens, Foxconn, and many others.

Whether it’s in the development process or in training and consulting, I have found that most companies face a series of challenges in software development and architecture transformation, and a significant portion of these challenges can possibly be solved through DDD. However, in actual work, I often hear statements about DDD like: “DDD is abstract and difficult to learn, hard to get started with; DDD sounds impressive, but it can’t be implemented; Does DDD really apply to microservices?” Let’s temporarily put aside prejudices and doubts, and listen to my stories about DDD over the years.

Me and My DDD #

Act 1: The Wonderful Encounter Between Me and DDD #

I remember in 2006, with an extremely excited mood, I began reading the book “Domain-Driven Design” written by Eric Evans. It was indeed a heavyweight masterpiece from which I learned the true essence of software development, and I also started applying it actively in practice.

However, after many years of being tempered by numerous software projects, I asked myself sincerely, have I really put DDD into practice? No, I only learned its ideas, but didn’t apply its methods. Why is that?

DDD is the way to deal with the core complexity of software, but at that time, everyone was busy developing new projects. How to code and develop a system quickly and release it quickly was the priority. For customers, domain-driven development was too slow. Besides, during that era, the business was not as complex, and DDD couldn’t fully leverage its advantages. But in recent years, things have gradually changed.

Act 2: The Heart-wrenching Legacy System #

In 2012, I took over a task of transforming a legacy system. The system was developed in 2002 and has undergone dozens of changes, big and small. The program has become a mess and the cost of maintenance is getting higher and higher. At this point, it is necessary to optimize and refactor it through proper reconstruction, but I found that there are many large functions and objects that run into thousands of lines, which are the worst-hit areas of software degradation. Why is that?

After deep contemplation, I quickly realized the root cause of the problem: this is the inevitable result of the business of the software evolving from simplicity to complexity. Software will become more and more complex and the code will become more and more abundant with changes. This means that the code cannot be crammed into the original simple program structure anymore. Instead, the program structure needs to be adjusted by decoupling what needs to be decoupled and splitting what needs to be split in order to implement new functionalities and maintain design quality. But how do we adjust? Maybe we can think clearly for the 1st, 2nd, and 3rd changes, but we can’t think clearly for the 10th, 20th, and 30th changes, and our design starts to lose its direction. What should we do? Once again, I fell into deep thoughts…

After several rounds of pondering and exploration, I finally found the key to prevent software degeneration, which is DDD (Domain-Driven Design). When a system goes through multiple changes and loses its direction, the root cause is complexity. The business logic and code become increasingly complex and difficult to understand. This is not an isolated case, but a problem that all software systems must face today.

By using DDD, when the system’s business becomes more and more complex, we can represent our understanding of the business as a domain model, which can guide software development correctly. When changes occur in the system, we can trace those changes through the domain model and map them back to the real world. Then, we can update the domain model based on the changes in the real world, and use the updated domain model to guide the program changes. This way, we can make correct designs and maintain a system at a low cost. This is particularly important for software systems with increasingly longer lifecycles.

Act 3: Who Will Save Microservices #

In 2015, the rapid development of Internet technology brought us unlimited room for growth. More and more industries have been considering: How do we transform into the Internet world? How do we expand Internet business? At this time, a powerful tool for Internet transformation emerged - microservices. It can help many industries cope with Internet business. So, we joined the trend of microservice transformation.

However, microservices are not a silver bullet, and they also have many pitfalls.

After splitting the system into microservices based on modules, we realized that each change required modifying multiple microservices. Not only did multiple teams need to make changes, but we also had to deploy and upgrade them simultaneously. Instead of reducing maintenance costs, it made system deployment more complicated compared to the past. We started questioning whether microservices were actually good. I fell into deep thoughts once again.

It was then that I noticed what Martin Fowler mentioned about “small and focused” when defining microservices. Many people understand “small” but neglect “focused,” which leads to a poorly maintainable microservice system. “Focused” means that a “small team maintains” each microservice independently. In other words, each demand change should be handled by a small team working on a specific microservice. Only in this way can we harness the advantages of microservices.

Through this analysis, we realized that designing microservices is not just a matter of technological architecture iteration, but it also requires higher requirements for the original design - “high cohesion within microservices and low coupling between microservices.” How can we achieve this? The answer is still DDD.

One of the important reasons for our microservice transformation is the complexity of the system. As the system scales larger and becomes more difficult to maintain, we need to split it into microservices. However, splitting into microservices does not mean that each microservice operates independently; they need to work together. It’s like a team that needs some methods to organize itself as it grows. DDD is exactly the practical method that helps us organize microservices.

Act 4: DDD, It’s Not Easy to Say I Love You #

In 2018, after a struggle, I finally convinced the development team to start using DDD (Domain-Driven Design). In the process, I realized that to make DDD work well in a team, we also need a technical platform that supports DDD and microservices.

With the support of this technical platform, the development team can focus more on understanding user needs and pain points. They can quickly develop satisfying features and deliver them quickly. As a result, not only does the amount of code decrease and the technical threshold decrease, but it also becomes easier to make changes and update technologies in the future. So, I began searching for a solution once again.

Soon, Uncle Bob’s Clean Architecture gave me a new perspective. The core of Clean Architecture is business logic (represented by the yellow and red parts in the diagram), which includes services, entities, and value objects derived from domain model analysis.

However, the most crucial design idea in Clean Architecture is decoupling business logic from technical frameworks through a series of adapters (represented by the green parts in the diagram). By doing so, upper-level developers can focus more on developing their business logic, reducing the technical threshold. Lower-level platform architects can evolve the architecture at a lower cost, keeping up with market and technological changes. Only by doing this can we keep up with the increasingly fierce market competition.

Image from “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” by Robert C. Martin

Not only that, but during my practical exploration, I also innovatively proposed single controllers, generic repositories, generic factories, and a tech platform architecture design that perfectly supports DDD and microservices. With these designs, the development team can better apply DDD in project development and build teams that truly understand the business, develop high-quality features, and deliver them quickly.

What Can You Learn from This Course? #

In my story, did you see yourself? Or did it remind you of the various difficulties you encounter in development?

For example:

• As a microservice developer, do you struggle with how to split and design microservices, leading to unreasonable division and making software maintenance and deployment difficult?
• As a business developer, do you find it challenging to make changes as the business becomes increasingly complex, especially when faced with new requirements? As a result, does the quality of your development suffer and the delivery speed slow down?
• As a system architect, do you have difficulties in confirming and planning system boundaries through domain modeling? Or do you struggle with building a technical platform to support the fast iteration of business and architecture changes?

So, in order to help you overcome the current “plight,” my team and I have integrated our practical experience with DDD and the “pitfalls” we encountered to create the content of this course.

This course combines refactoring, high-quality software design, and microservices, ultimately guiding development teams to transform from their current state to a domain-driven design and microservices architecture. Through refactoring, we aim to build a tech platform that supports microservices and domain-driven design, enabling faster software development and delivery.

• Module 1: Coping with Software Complexity (01 ~ 06): Through a series of real cases, we explain how to use DDD to deal with increasingly complex business systems while maintaining low-cost maintenance and high-quality design. After completing this module, you will understand the basic concepts of DDD and how to apply it in practical work.
• Module 2: Domain Modeling Practice (07 ~ 09): Using an online food ordering system as an example, we demonstrate the complete development process of DDD from business modeling and event storming to microservice splitting and technical implementation. This module delves into the underlying principles and specific implementation of DDD. After completing this module, you will be able to master the domain modeling process and apply it in practical scenarios with microservices.
• Module 3: Microservices Tech Platform for DDD (10 ~ 13): This module mainly explains how to use Clean Architecture to build a tech platform that supports both DDD and microservices. It also demonstrates how to achieve fast business delivery and architectural evolution through this platform. After completing this module, you will be able to architect a tech platform from an architect’s perspective and support rapid delivery and architectural evolution for development teams.
• Module 4: Project Practice (14 ~ 15): We use two practical cases in the domains of microservices + AI and embedded systems + IoT to demonstrate the process of business modeling, system planning, and design using DDD. This section can guide you in applying DDD to future practical projects.
• Module 5: Code Implementation Demonstration (16 ~ 17): We provide two concise and reusable code demonstrations to help you apply the knowledge and theory in development. You can directly use the parts you need.

Instructor’s Message #

Finally, I want to say that learning and applying DDD is not easy. But in this course, I will be like a mentor next to you, using my years of experience, practice, and thoughts to help you learn this course in an easy and efficient way. I hope that you can apply DDD to your work faster and more effectively.

Believe me, whether you are a senior architect or a junior developer, the overall architecture methodology of DDD and its design ideas will bring energy to your work.