Microservices (Microservices architecture) and DDD (Domain-driven design) are two of the hottest technology terms of the moment. In my consulting work in the last two years, I was always asked by different teams and roles, which also prompted me to think why these two technical terms are so deeply bound and what is the relationship between them?

Service for higher business responsiveness

From the point of view of the invention of two words, there is no causal relationship between them.

DDD is the title of Eric Evans’ book published in 2003, and is the origin of the name of this architectural design method. The idea of DDD is to align our software implementation with an evolving architectural model derived from our business requirements. This evolutionary design approach was challenging at the time, and the more popular solution to architectural design complexity was layering: data architecture, service architecture, middleware architecture, etc. MVC has also become standard in Internet application development.

Fast-forward a decade, and Martin Fowler and James Lewis, the UK architect at ThoughtWorks, sat down to analyze several large, complex systems that could continue to evolve, came up with nine core characteristics, and then used Microservices to define an architecture that had those characteristics. Microservices took over the software industry as Google, Netflix, Amazon and other stars took over. At this point, many people will ask how the microservices architecture is designed, and people in the industry will say that DDD is a good approach, including Martin Fowler, who wrote the introduction to the original DDD book;) As a result, DDD began to catch on 10 years after it was defined.

From my perspective, if causality is to be found, the fundamental driving force is the increasing responsiveness of software systems in the age of technology, while the complexity of systems increases with the diversification of businesses. How to manage such high complexity has become a challenge that every Enterprise must face, so that the industry began to sum up this model as Responsive Enterprise, and most of the principles summarized in the model are to better adapt to the high complexity brought by environmental uncertainty.

Separate complexity from a business perspective

There is a limit to how much complexity each person can recognize. When faced with high complexity, we will do separation of concerns, which is the most basic philosophical principle. Obviously, we also apply this principle when modeling complex business scenarios. At this time, two dimensions can be used to separate concerns:

  • Technical dimension separation, layering ideas like MVC are widely accepted.
  • The business dimension is separated and the system is divided according to different business formats, such as pre-sales, sales and after-sales.

Neither of the above two dimensions is superior to the other, and both dimensions must be used when dealing with complex problems. However, in order to effectively respond to business changes, the architecture of microservices emphasizes the separation of concerns from the business dimension to cope with high complexity. This is one of the characteristics that distinguishes traditional SOA architectures, such as the ESB (Industrial Service Bus), which was born in the era of SOA, as a typical middleware separated from technical concerns.

As the business changes, we also see the ESB becoming an architectural anti-pattern, in which a large number of business rules and processes are encapsulated within the ESB, making the ESB a source of unmanageable complexity that undermines the benefits previously promised by the SOA architecture. Of course, the Microservices architecture is not the next generation OF SOA architecture, and there have been many articles on this topic that I won’t cover in this article.

So DDD as an architectural design method at heart and Microservices as an architectural style are both means of separating complexity from a business perspective in pursuit of high responsiveness goals.

If you think your architecture doesn’t need this responsiveness in this day and age, ask your friends and colleagues who have maintained systems for more than 3 years and they will tell you what a pain it is. In fact, many enterprises have gone “crazy” in their pursuit of this responsiveness, which may not have been anticipated by either of the microservices definers.

Their definition paper comes with a strong note of caution, but in this age of technology, the possible risks of microservice architecture implementation are almost negligible compared to the market opportunities that high responsiveness may bring in the future. The success of Netflix alone is enough for most companies to choose microservices as their architectural style without hesitation.

Architecting progressive unification of business and technology

If The goals of Microservices and DDD are the same, how will they be different?

To explain this, let’s simplify architectural design into the following three levels:

  • Business architecture: Design business modules and interactions according to business requirements.
  • System architecture: Design the modules of systems and subsystems according to business requirements.
  • Technology architecture: Determine the technology and framework to be adopted based on business requirements.

Obviously, these three should be in order in a specific architectural design activity, but not necessarily which comes first. For example, for a simple Web application, many people will say that MVC is standard (the system architecture is determined first), or some people will say that RoR is fast (the technical architecture is determined first). Perhaps this sequence makes sense in a given business scenario.

(Hierarchy of architectural design work and traditional responsibility)

This is when we add complex business requirements and rapid market change to the two environmental variables, and the sequence becomes interesting. As a result, we’ve heard stories of Internet service platforms coming out of their infancy “rewriting” their systems (from PHP to Java) and articles rethinking the rigidities of MVC (bloated presentation layers). Experienced architects of this change will be out of empathy for the DDD platform, its reason is “skip” or “up” business architecture clearly show that designed the architecture of the focus is not on the responsiveness of the business, because business can change point analysis has not been guiding the design of the system and the technical architecture.

The core appeal of DDD is to bind the business architecture to the system architecture, so that when we adapt the business architecture in response to business changes, the system architecture changes as well.

The result of this change is twofold:

  • The sorting of business architecture and system architecture is synchronous and progressive, and the result is that the business context divided is bound to the system module structure.
  • The technology architecture is decoupled and the most appropriate implementation technology can be selected based on the system architecture of the segmented business context.

The first point is clearly the one we must follow to generate microservices segmentation, because microservices pursue reuse at the business level, so the design of the system must be business aligned. The second is the nature of microservices architecture: “decentralized” governance techniques and data management. As an approach to architectural design, DDD practices, including the recent popularity of Event Storming, are actually facilitating progressive recognition of business and system architecture.

In a DDD workshop, a colleague asked “Do you need to continue to do architecture design when you can’t tell the business story clearly?” Classic comment. The entire DDD approach does not involve a specific technical architecture implementation, and this selection is often “delegated” to the actual development team.

It is worth mentioning that the use of DDD as an architectural design approach does not necessarily lead to the architectural style of Mircoservices. It is often recommended to use large-grained services to contain the inconsistencies found during business analysis to avoid the bi-directional modification costs caused by excessive changes after splitting.

Architecture design for cross-functional collaboration

The gradual recognition of business and systems has changed many previous architectural working patterns, and it is easy to feel the importance of business experts in the adoption of DDD. If there is still a desire for the business to be able to explain the requirements to the architect once and for all, THEN I suggest students who wish to attend an architectural design discussion in which they are not familiar with the business. It’s easy to conclude that the business doesn’t know what they want either. Business people, of course, must resist the idea of participating in an architectural design approach.

The successful use of DDD is based on creating an environment where the two different cognitive models, business and system, are gradually unified.

(Business Architecture and System Architecture Design)

So “unfortunately” if you can’t build a new architecture design team across businesses and technologies, your DDD practice won’t have a foundation for success, and moving on to a microservices architecture can be a disaster. Fortunately, this kind of cross-functional organizational structure is already standard for “adopting” microservices architectures like Amazon in the previous article, so you don’t have to argue that it’s feasible. The remaining key is how to get people from different backgrounds to work together. This will be the next big thing in DDD, as we see more and more of our iconic Event Storming of collaborative work.

Never-ending DDD and evolving Microservices

DDD is addictive, and this collaboration will become the norm as it turns out that the modeling process allows business experts to understand service partitioning (system modules) better and the architectural design to understand business requirements better. In this age of tech@core, such integration will become the core competitiveness of enterprises.

Of course, when you start using the DDD approach, don’t assume that having a so-called DDD workshop for each system will determine the best service segmentation. Business change is continuous, and every business architecture change must affect the system architecture change. A good domain architecture binds the business and the system, enabling people on both sides to communicate in a common language, which is not easy to establish, but even harder to sustain.

Successful DDD adoption occurs throughout the life cycle of the system, where business and technology collaboration occurs continuously.

The final attribute of Microservices: “evolutionary” design – also makes it clear that design is an ongoing activity. DDD provides a way of working in line with this microservice nature, allowing evolutions to land. It is worth mentioning that in my recent experience, the most difficult part of this evolution to recognize is the most obvious “unified language” in DDD. Once a business concept, “customer,” has been formed, few teams have been able to keep an eye on whether the meaning of “customer” has changed as the market has changed.

In contrast to traditional SOA, microservice unbundling is also dynamic, mattxianjing describes in his article the evolution of service unbundling as a system adopts a microservice architecture. The illusion that there won’t be an ESB to keep things going has been debunked several times in the past decade. The benefit of DDD is that both business and technical people can understand this change in collaboration without the embarrassment of business people complaining about technical architecture and technical people feeling that business people are changing their minds.

You need to be the tall one!

Martin Fowler drew the following diagram in his article on the definition of Microservies, commenting that “you have to have that height” as a metaphor for the capability requirements of microservices implementation. In terms of architectural modeling, I think DDD should be a must for a team, both business people and product designers on the team.

(Preconditions for microservices)

It is interesting that Service Design is also a hot topic in the field of user experience Design around the world. The whole Service chain is designed from the perspective of users. For example, for the popular shared bikes, a successful service design should start from the user’s demand for cars to the end of the ride, rather than just designing a bike that can be unlocked on the Internet.

We can find many similarities between Service Deisgn and DDD in principle, such as user-centric and collaborative design. To borrow the tall expression above:

You definitely need to be tall when it comes to business needs recognition and cross-functional collaboration!

As a domestic domain driven design (DDD) thought and practice leader, ThoughtWorks architectural consultants hope and community partners, to organize a domain driven design summit, thus creating a domestic domain driven design (DDD) practitioners communicate with each other and share the successful experience of your team. We also hope that through this conference, the architectural ideas of domain-driven Design (DDD) can be recognized by more people in China, thus forming a larger scale effect.

We have decided to hold DDD China Conference 2017 in Beijing on December 8 and 9, 2017. We are now soliciting a wide range of topics from domestic peers and practitioners of dome-driven design (DDD) : jinshuju.net/f/f8Puf5