For example: how to translate business requirements into software design accurately? How do you get your team to focus on the business, not the technology? How to solve cross-functional language communication problems, such as communication barriers between development and business? How to solve the problem of software systems not rotting over time…
In order to solve these problems, Eric Evans proposed an effective methodology 15 years ago, namely Domain Driven Design (DDD), which earned Eric Evans a good reputation in the global IT circle.
It is a little regrettable that DDD is not well understood in China, and we seldom hear of projects and software that claim to apply DDD principles.
People who have not mastered DDD complain that the technology is too obscure to start with in real life. Those who have mastered it find it not so difficult, but a natural choice of design method.
What does DDD mean to architects and software development engineers? What does it mean for business? How should we properly understand DDD and use it? How do YOU become a DDD expert?
Recently, the 2nd DDD China Conference (2018 DDD China Conference) was held in Beijing, and I had the opportunity to interview two practical DDD experts. They are Zhang Yi, Director of Information Technology for Civil Aviation, topic Production of DDD China Summit. Zhou Yugang, Senior consultant at ThoughtWorks. Let’s take a look at their experiences.
How to learn and use DDD?
Zhang Yi, who graduated from university in 1998, was already a veteran programmer with rich programming experience in 2006, when he first came into contact with DDD through the book Domain Driven Design by Eric Evans.
“At that time, learning DDD mainly depends on reading books and thinking by myself, because there is no one to teach, and there is no atmosphere.” Younglab said.
At the same time, he also began to gradually try to use DDD in his work, because Eric’s book is difficult to understand and difficult to understand, so in the process of practice, most of the time, he was only half-understanding, so that he continued to practice for more than 10 years.
“For partial business systems such as delayed settlement and collaborative decision making, we will try to use DDD to improve the system architecture and code quality, but the process is not smooth and the progress is halting. There’s a time frame issue, and there’s a team member capability issue.” Younglab said.
In retrospect, a project is rarely done in the way of DDD. Many projects are difficult to be done in the way of DDD due to historical legacy issues and differences in the understanding of DDD by the team, but some DDD ideas will be introduced. When you don’t have the answer, look at the essence of design, whether or not it fits into Eric Evans’s book.
Zhou Yu just got in contact with DDD in 2009, slightly later than Zhang Yi. It is hard to imagine that he is a programmer who once worked as a tour guide. The reason for Zhou Yu to learn DDD is that he encountered many challenges in daily programming work, such as a reservation process, how to do object-oriented? What is the object? How do you collaborate?
Until one day, he came across Eric’s book and just saw the first half of the tactical design. In order to further learn DDD, he even went to Stack Overflow to register an account, just to see how others learn DDD. In fact, go to foreign websites to look is also helpless, because searched the domestic website, found that no one is talking about DDD.
In fact, he couldn’t wait to practice on his own projects before he had even read the second half of the book.
As the Team Leader, he has great autonomy in his work, so it is easier to start trying in his own project, but the process is tortuous. “Because you didn’t know what DDD was at first? Try to understand it while practicing it in your own projects, “says Zhou.
When the knowledge in books or other people’s cases do not fit the actual project, how should we accumulate our own experience in the process of practice? Zhou Yugang believes that we should jump out of this field to design, because what we pursue is not whether to use DDD, but what effect can be achieved with DDD.
How to understand DDD correctly?
Why do many people find DDD difficult to learn? Because, it is a thought, a method. Zhou yugang said.
At first you think DDD is an object-oriented modeling method that tells you how to do enterprise application architecture, and then you find that it tells you how to identify problems, such as enterprise application problems, business domain problems, which should be taken apart…
In fact, DDD was originally an object-oriented modeling method that integrated software system analysis and design, and has now evolved into a domain modeling and analysis method for large complex systems.
Zhang Yi believes that to understand DDD, we must first make clear its historical background and context.
Although it has been almost 15 years since Eric Evans published his landmark book, Domain-Driven Design, and DDD has changed a bit, why did Eric Evans propose DDD? This is what you need to know to learn DDD.
In 2004, Eric Evans proposed DDD, just as object-oriented design was in vogue, UML was also in vogue, but at this point in time, software design has a fatal problem, software system development is still from a database perspective. Of course, this involves a variety of reasons, but also need to understand.
First, the software system development at that time did not have the diversity of today, and the source of system operation was still the operation database, which was just the difference between simple and complex.
Second, the software industry itself is very much like a software workshop, relying on the old generation of new ways of inheritance. And the old people first contact is database-oriented design, so, although there is already object-oriented, but the developer’s development work is still based on database driven.
As a result, Eric Evans’ book emphasizes that it is difficult to enjoy the benefits of DDD if you take a database-oriented design approach to modeling. Zhang Yi believes that the most crucial point to correctly understand DDD is to understand Domain Driven and drive it from this perspective, which needs to ensure two points:
First, when designing, do not consider technical implementation at all, only consider business, only consider domain.
Second, DDD is not purely a software development method, emphasis on Domain, emphasis on the Domain must have communication, there must be collaboration, many people do DDD is difficult, even do not do well, is there is no business personnel involved, business based communication mechanism is the core of DDD.
What does DDD mean for enterprises, architects, and developers?
In the opinion of Zhou Yugang and Zhang Yi, DDD has two aspects of value for enterprises. First, it can help enterprises identify their core areas and decide the use of enterprise resources. Second, it can help enterprises optimize the organizational structure and culture of the team.
Zhou yugang said that from the perspective of value orientation, DDD is a strategy for enterprises, which can help enterprises identify their core areas and determine how to use enterprise resources to support core competitiveness. For example, core areas need to spend a lot of energy to do, while non-core areas can be done in a simpler and faster way, or even directly purchase mature software suite.
Zhang Yi elaborated on DDD’s value to the team’s organizational structure and culture. He said that most of the time, it’s not the technical problems, but the organizational structure and culture of the team. Of course, this is not purely DDD driven, it can be done in an agile or lean way.
For architects, DDD is helpful for architects to implement strategic design, said Zhou Yugang. Because DDD solves the problem of language communication between different departments, it establishes a common language between business, product and development to improve communication efficiency. For developers, DDD is more practical, helping developers develop the right code for their projects.
Zhang Yi believes that for architects, DDD can help architects confirm system and domain boundaries. Even if there are problems inside, as long as the boundaries are stable, the system will not be affected too much.
The boundary control is good, the overall architecture will be clear, the control will be more intuitive, such architecture is not easy to rot, the biggest problem of the current software system, it will slowly rot over time. And with boundaries well controlled, it’s relatively easy to get code down to the implementation level.
For developers, Zhang yi believes DDD has two main levels of value:
A developer who does not want to be an architect is not a good developer. Developers should not only be satisfied with what the architect assigns them, but also have DDD knowledge. It’s hard to improve if you know what the architect is doing, but you don’t know why, and it’s not good to implement it.
Second, integrated knowledge structure. From the perspective of DDD, because DDD is more business-oriented and wants to be viewed from a business perspective, DDD can better match some of the most basic design principles that developers have mastered.