DDD & MicroServices

This is a creation in Article, where the information may have evolved or changed.

MicroServices (micro-service architecture) and DDD (domain driven design) are the hottest two technical vocabularies nowadays. In the last two years of consulting work will always be asked by different teams and roles, which also prompted me to think about why these two technical words are so deeply binding, what is the relationship between them?

Service for higher business responsiveness

First of all, from the invention of two words, they have no causal relationship. DDD is the title of Eric Evans published in 2003, and it is also the origin of the architectural design method name. The idea of DDD is to keep our software implementations consistent with an evolving architecture model, which comes from our business needs. This evolutionary design approach seemed challenging at the time, and the more prevalent approach to solving architectural design complexity was layering: data architecture, service architecture, middleware architecture, etc. MVC is also a basic standard in the field of Internet application development.

Soon after 10 years, Martin Fowler and ThoughtWorks, British architect James Lewis, sat down together to analyze several large and complex systems that could continue to evolve, summarizing 9 core traits, It then uses microservices to define the architecture that holds these traits. Since then, Google, Netflix, Amazon and a range of star enterprises are the seat, MicroServices began to sweep the entire software industry. At this time many people will ask how the MicroServices architecture is designed, the industry will say that DDD is a good way, including the micro-service definition of Martin Fowler, after all, the order of the DDD book is he gave it, and DDD began to be defined 10 years after the fire.

From my point of view, if we really need to find a causal relationship, the most fundamental driving force comes from the technology era of software system (digital) response requirements of the continuous improvement, and the complexity of the system with the diversification of the business is increasing. How to harness such high complexity has become a challenge for every business, so that the industry has begun to summarize this model as a responsive enterprise (responsive Enterprises), Most of the principles summarized in the model are designed to better adapt to the high complexity of environmental uncertainties.

Separation of complexity from a business perspective

The complexity of each person's ability to perceive is limited, and in the face of high complexity we do the separation of concerns, which is one of the most basic philosophical principles. Obviously, we also apply this principle when modeling complex business scenarios. At this point, the separation of concerns can generally be set from two dimensions:

• Separation of technology dimensions, layered thinking like MVC is widely accepted.
• Business dimension separation, according to the different sectors of the system, such as by pre-sale, sales, after-sale division.

The above two dimensions do not have a good or inferior point, when dealing with complex problems must be used, but in order to be able to effectively respond to business changes, microservices architecture More emphasis on the business dimension of separation of concerns to deal with high complexity . This is one of the traits that are significantly different from traditional SOA architectures, such as the ESB (Industrial service Bus), which was born in the traditional SOA era, is a typical middleware that separates the technical concerns. As the business changes, we also see the ESB as an architectural anti-pattern, where a large number of business rules and processes are encapsulated in the ESB, making the ESB an unmanageable source of complexity that undermines the benefits of the SOA architecture before it is committed. Of course microservices architecture is not a new generation of SOA architecture so simple, there are many articles in the discussion of this topic, this article is not launched.

Therefore, DDD as an architectural design approach and microservices as an architectural style are the means of separating complexity from the business perspective for the purpose of pursuing high responsiveness.

If you still feel that your architecture doesn't need this kind of responsiveness, I suggest you ask your friends or colleagues who maintain the system for more than 3 years, and they will tell you what kind of pain it is. In fact, many companies have been "crazy" about this responsiveness, which is also likely to be unexpected for the two-bit definition of microservices.

They use a strong warning tone in the definition of the article, but in this technology age, the potential risks of implementing a microservices architecture can be negligible compared to the potential market opportunities in the future. A Netflix success is enough for most businesses to choose microservices as their architectural style without hesitation.

Business and technology incremental Unified architecture Design

If MicroServices and DDD achieve the same goal, then what is the difference between the specific practice and the previous one?

To explain this, we have simplified the architecture design to work on the following three levels:

• Business Architecture: Design business modules and interactions based on business requirements.
• System Architecture: Design the modules of systems and subsystems according to business requirements.
• Technology architecture: The technology and framework used to determine the business requirements.

Obviously these three in a specific architecture design activities should be sequential, but not necessarily the first, such as a simple Web application, many people will say that MVC is standard (first to determine the system architecture), or some people say with Ror fast (first to determine the technical architecture). In a given business scenario, the order may be justified.

Architectural design work layering and the traditional sense of head

This is an interesting order when we increase the complexity of business requirements and rapid market changes . So we heard that many of the Internet service platforms that came out of the start-up were "rewriting" their systems (from PHP to Java), and many articles began to rethink the rigidity of MVC (the bloated presentation layer). Architects who have undergone such changes will empathize with the DDD platform for the reason that the "skip" (or "post-fill") Business architecture clearly indicates that the architectural focus of the design is not on the responsiveness of the business, as the potential point of change in the business is not analyzed to guide the design of the system and technology architecture.

The core requirement of DDD is the ability to bind business architectures and system architectures so that when we respond to business changes, the changes in the system architecture are spontaneous.

The result of this change is two:

• The carding of the business architecture and the carding of the system architecture are synchronous and gradual, and the result is that the business context and the system module structure are bound.
• The technical architecture is decoupled, and the most appropriate implementation technology can be chosen based on the system architecture of the business context in which it is divided.

The 1th is clearly what we have to follow when it comes to the division of MicroServices, because microservices pursue business-level reuse, so designed systems must be aligned with the business. The 2nd is the quality of the MicroServices architecture: "De-centric" governance technology and data management. As an architectural approach, the various practices of DDD, including the recently popular event storming (incident storm), are actually progressive perceptions that facilitate business and system architecture grooming.

In a DDD workshop, a colleague gave the words "you don't even know the business story, do you need to continue with the architecture design?" "Such a classic comment. And the whole method of DDD does not involve the implementation of a specific technical architecture, the right to choose a lot of time to be "decentralized" to the real development team.

It is worth mentioning that the use of DDD this architecture design approach does not necessarily produce mircoservices this architectural style, it is often recommended to use a large granular service to include the business analysis process found in the uncertainty points, in order to avoid the split after the frequent changes in the cost of bidirectional modification.

Architecture design for cross-functional collaboration

The gradual perception of business and systems has changed many of the previous architectural work patterns, and it is easy to feel the importance of business experts in the process of using DDD. And if someone is hoping that the business can give the architect a clear need at once, then I suggest that students with such hope go to the architectural design discussion in person who is unfamiliar with the business area. You will easily conclude that "the business does not understand what he wants." Of course, the business people heard to participate in some kind of (software) architecture design method, the heart must also be inconsistent.

The foundation of DDD's successful use is to create an environment in which the two different cognitive models of business and systems are gradually unified.

Business architecture and System architecture design

So "unfortunate" is that if you can't build a new architecture design team across business and technology, your DDD practice has no foundation for success, and then using a microservices architecture can be a disaster. Fortunately, this cross-functional organizational structure is already standard in the previous article, "adopting" a microservices architecture enterprise, such as Amazon, and you no longer have to justify the implementation of this thing. The rest of the key is how to get people from different backgrounds to work together. It is also possible to see the next hot spot in the DDD field, and a modular collaboration workshop like event storming will appear more in the eyes of everyone.

The never-ending ddd and evolution of the MicroServices

DDD is addictive, and this collaboration becomes the norm when you find that the business experts know more about service partitioning (System modules) through this modeling process, and architecture design understands business needs. In this tech@core era, such integration will become the core competitiveness of enterprises.

Of course, when you first start using the DDD approach, don't assume that each system will be able to find the best service division by doing a so-called DDD workshop. Business changes are ongoing, and each change in the business architecture inevitably affects the changes in the system architecture. A good domain architecture binds business and systems, allowing both sides to communicate in a unified language, which is difficult to build and continues to work harder.

Successful DDD methods are used throughout the lifecycle of the system, and the collaboration between business and technology continues to occur.

MicroServices's last trait: "Evolutionary" design – also clarifies that design is an ongoing activity. DDD provides a way to work with this micro-service trait, allowing evolution to fall into the ground. It is worth mentioning that in the recent experience of the author, the most difficult to recognize in this evolution process is the most obvious "unified language" in DDD. When people form a business concept-"customer", few teams can continuously examine whether the "customer" has changed with the changes in the market.

Compared to the traditional SOA, the split of MicroServices is also dynamic, Zhuo in his own article describes a system using micro-service architecture process of service split evolution. There will not be an ESB to status quo, a fantasy that has been beaten several times in the past 10 years. The advantage of DDD is that both business and technical staff can understand this change in collaboration, without getting bogged down in business people complaining that the technology architecture is not known, and technical staff feel that the business people loose embarrassment.

You need to be that tall man!

Martin Fowler the following figure in Microservies's definition article, commenting that "you must have that height" to metaphor the ability requirements for microservices implementation. In terms of architectural modeling, I think DDD should be a team that has to master, including the team's business people and product designers.

Micro-service Pre-condition schematic

It is interesting that service design is also a hot topic in the field of user experience design in the world, from the user's point of view to design the entire service chain. For example, the popular shared bike, a successful service design should be from the user to start a useful car demand to the end of the final ride to complete the departure, and not just to design a car can be unlocked by the Internet of bicycles.

We can find a lot of similarities between service deisgn and DDD in principle, such as User Center and collaborative design. Borrow the tall saying:

You need to be tall in terms of business needs cognition and cross-functional collaboration!

For more insights, please follow the public number: Stevok