In many microservices development teams in the design and implementation of microservices feel that as long as the original unit is small, it is microservices. But this is not necessarily the right microservice, it may just be a small unit stripped down. In this article, let’s continue with this topic and first look at why small monomers are removed.
Path-dependent dilemmas for designing microservices
Before the emergence of microservices architecture, almost all software systems are built with single architecture, so the development path favored by most software developers is single architecture mode. In this context, according to the path-dependent laws of economics and psychology, when these developers want to split the original large unit into multiple parts based on new technology, they will habitually design each part with the unit architecture they are best at.
Path dependence law: it means that the technological evolution and institutional change in human society are similar to the inertia in physics, that is, once entering a certain path (no matter “good” or “bad”), they may be dependent on this path. Once you make a choice, it’s like you’re on a path of no return, and the power of inertia can make that choice self-reinforcing and make it hard to get out. The first person to make “path dependence” theory widely known was Douglas North, who won the Nobel Prize in Economics in 1993 for his successful explanation of the evolution of economic institutions with “path dependence” theory. Once the theory of path dependence was developed, it was widely applied to all aspects of choice and habit. To some extent, all the choices people make are horribly influenced by path dependence. The choices people make in the past determine their possible choices in the present. Everything people think about habits can be explained by “path dependence”.
In reality, we often see this rule happening everywhere. When wechat first came out, many people said it was just QQ on mobile phones, and when moments of friends came out, they said it was just copying Weibo. Many times when you are excited to introduce a new thing to a friend, a friend can make you despair: this is not XXX? The reason for this is that when human beings come into contact with new knowledge and concepts, they will subconsciously apply the concepts they know before. Such thinking mode is the mode that human beings use when they learn new things since childhood, and it has been solidified into a part of the operating system of our brain. By understanding this principle, it is easy to understand that software engineers who have been working on a monolithic architecture for many years, when asked to design and develop with a microservices architecture, have a natural reaction: isn’t that just making the original monolithic smaller? But do these “microservices” really deliver the benefits of microservices architecture? Can it really improve a company’s digital responsiveness? Constantly changing software requirements and often seen as inefficient software development has been the industry’s most difficult problem to solve, from waterfall to Agile, are trying to find a solution to this problem, Domain Driven Design is one of the prescriptions, and with more than a decade of practice, We have found that this prescription has its own unique characteristics, so let’s take a look at it first.
DDD, brief
The concept of domain-driven design emerged in 2003, when software was still in the transition from CS to BS and the Agile Manifesto was only two years old. But Eric Evans as working in the enterprise applications technology consultant for many years, keen found in the software development industry limits (especially for enterprise applications) have begun to emerge a trend, he put the thoughts become domain driven design, also published a book at the same time, in the book to share their modeling method used in the software project in the design, It also provides a framework for design decision makers. But since then DDD did not become more popular and agile, if you would like to ask the reason, on the one hand, I think, is this method there are many new concepts, new word such as aggregation, bounded context, value objects, etc., to understand the abstract concept itself is difficult, so the study and application of DDD curve is very steep. On the other hand, as the only “official textbook” “Domain-Driven Design” at that time, reading this book was a very painful process, and there were often jumps in content organization, so many people would put down after just a few pages. There are some high entry barrier, but for software engineers like intellectual challenge, this is a difficult toy slight is a little high, so in smaller groups, a group of people began to gradually able to control this toy, and it can be used to guide the design can control the complexity of the business software applications. Although most software applications at the time were monolithic, it was still possible to design monolithic applications that were easy to maintain and responsive to changing requirements using DDD.
In 2013, as various distributed infrastructures gradually matured and SOA architecture applications were not so smooth in practice, Martin Fowler and James Lewis summarized a new trend of distributed architecture as microservice architecture. Then the wind of microservices began to blow, and software engineers found a problem that although guiding the application characteristics of microservices architecture, they did not know how to split the original large unit into microservices. However, engineers familiar with THE DDD approach found that because DDD can effectively dismantle software systems from a business perspective, DDD particularly fits one of the characteristics of microservices: building around business capabilities. Therefore, the microservices split out of DDD are more reasonable and can achieve high cohesion and low coupling, and then microservices DDD welcomed its second spring. Let’s take a look at what DDD does from the perspective of software engineering.
DDD speculative
Since the invention of computer, people have used words to express the change of the world: electronic, information, digital. There is a word “transformation” in these words, which represents the transformation of human beings gradually from the original physical world of concepts, one by one, to the virtual world of computers. However, in the process of transformation, there must be a process of translation and design because the underlying logic and language of the two worlds are not consistent. This translation process has existed since the first days of software, and because of this translation process, business and development often feel like two opposing classes of people who cannot communicate with each other.
So some of the biggest names in software engineering began to wonder if there was a way to ease the translation process. Then we invented object-oriented languages, and we started trying to make the computer world have the concept of objects in the physical world. Object oriented is not enough, so here comes DDD, which defines some basic concepts and then tries to get both business and development to understand them, and then gets domain experts to describe the business using those concepts, and because of the prescribed concepts, development can understand the domain business very well. And the software can be implemented according to the way of domain business design. This is the original purpose of DDD: to bind the business architecture to the system architecture.
Later, I found that this method can not only do a good job in translation, but also help businesses to divide the boundaries of the field, which field is their core value and which field should be developed in the future. It can even serve as a reference for the organization’s strategic planning. The reason for this is the convergence of the physical world and the virtual world.
For example, if I wanted to buy an item in the physical world, I would need a ledger to keep track of what items came in, how many items were purchased for each order, and how much money was made for each item. These jobs in the computer world should also have the concepts of goods, books, orders, order details, and when I say that selling goods requires being able to deduct inventory from the books. In the computer world, it would be the order object that calls the ledger object to deduct inventory after completion. In this way, each business logic can easily find its corresponding object in the software to implement.
Get out of the design microservices split dilemma with DDD
As described above, you can bind business architecture and system architecture using DDD. What does this bind have to do with microservices? The so-called micro services split difficult, in fact, the root cause is do not know where the boundary. When DDD is used for business analysis, aggregation is first used to divide highly related business concepts under a boundary, and the aggregation and aggregation can only be accessed through the aggregation root, which is the first boundary. Then, on the basis of aggregation, the limiting context is defined according to business relevance, business change frequency, organizational structure and other constraints, which is the second level of boundary. With these two layers of boundaries as constraints and constraints, the boundaries of microservices are clear and it is not difficult to break them apart.
And based on the model with boundary of DDD design minimum atom is polymerization, polymerization and polymerization between because only through polymerization are interlinked to root, so when you need to put a polymerization from a bounded context to move to another bounded context, the movement of the very low cost can be easily on service refactoring, So that we don’t have to worry about whether or not we should split microservices in this way? There are too few microservices being dismantled and we will have to dismantle the problem again. Therefore, after rigorous theoretical reasoning and a number of practical projects, ThoughtWorks believes THAT DDD is currently the best practice for microservices design in the software engineering industry. Although the cost of learning and using DDD is a bit high, Chinese enterprises should try DDD to learn about advanced software engineering methods if they want to move from the cold weapon era to the hot weapon era in terms of software development capability.
This article is reprinted from: tinyurl.com/yxarsor5
