When DDD Meets Microservices
Definition of Distributed Systems
Before we can talk about this, we need to agree on what a distributed system is. In my opinion, the criterion for determining whether a system is distributed is whether there is cross-process communication in the system. It is the process that determines how collaboration and communication takes place, leading to two fundamentally different programming models.
- In-process programming model
- Cross-process programming model
The difference between them is the way the components are called on each other. In the case of Java, the objects and variables that reside in the same JVM are placed in heap or stack memory, and object calls (including method calls) are a form of memory addressing. The Java language creates an instance by using the new keyword to get a pointer to that instance so that the properties and methods of that instance can be called.
The way in which calls are made between cross-process components is inherently different from in-process calls. While there are various implementations of cross-process communication mechanisms, they all have the same factors to consider and need to take into account.
- Inter-process communication protocols
- How to address
- Serialization and deserialization of messages
On top of that, there are huge differences in resource management, transaction consistency, and deployment due to cross-process communication.
Clearly, the inherent complexity of cross-process communication brings about a change in the programming model, but its ability to make more efficient use of hardware resources is the main goal of distributed systems. Therefore, in the current historical context of IT development, it makes sense for us to define distributed systems by using processes as boundaries.
Description. The concept of process differs slightly from language platform to language platform, and naturally the communication mechanism differs as well. Java processes are equivalent to operating system processes, but Erlang has a different, more lightweight concept of processes than Go.
The way in which calls are made between cross-process components is actually an abstraction of the communication mechanism, which in turn actually encompasses.
- Inter-process communication mechanisms (e.g. shared memory, pipes, sockets)
- Structured communication mechanisms (e.g. RPC)
- Middleware communication mechanisms (distributed objects such as CORBA, component middleware such as EJB, messaging middleware, service-oriented and REST)
Discussion of Container for C4 model
Simon Brown has proposed his own C4 model, as shown below.
Our division of Container can be defined by using processes as the boundary of the division, or what I consider to be the "physical boundary". So Container can be considered part of the physical view in addition to being a constituent element of the logical view in the architecture.
It is no coincidence that Alistair Cockburn's proposed hexagonal architecture (aka port-adapter pattern) is an echo of Container in its boundary implications. The boundary of the external hexagon in the figure below is a physical boundary, which, following the previous analysis, we can consider as a process boundary.
Microservices and Bounded Context
A microservice, as a tiny service that can be deployed independently, is inherently an autonomous service that is physically isolated. From a physical viewpoint, a microservice is a Container in the C4 model, which is the hexagon in the hexagonal architecture. If we correspond the hexagonal architecture to the Bounded Context of DDD, then we can introduce the strategic design of DDD to delineate the service boundaries and thus help us in microservice design.
A typical Bounded Context can have its own domain model, access proprietary databases, and can introduce "dependency injection" to satisfy what Uncle Bob calls Clean Architecture ideas. Isn't the architecture of Bounded Context, shown below, exactly what could be represented as a microservice?
Context Map's Explanation of Microservices
Thinking about the Bounded Context in DDD, one can focus on two points.
- Relationship between Bounded Context and Domain
- Context Map
If we consider that there is a correspondence between Bounded Context and Domain, it means that microservices can be designed from the business architecture level. Using use cases, common languages, or other means can help us identify Bounded Context and thus get relatively reasonable service boundaries.
To determine whether the design of microservices is reasonable, you can further verify and discern the division of Bounded Context and sort out the relationship between them by using the Context Map of DDD.
Eric Evans, in his book DDD, lists nine types of Context Map, which can basically be categorized as.
- Collaborative approach between teams
- The way processes are integrated with each other
Why?Bounded Context The relationship between can be understood as being Collaborative approach between teams this (Cantonese)？ The theoretical basis comes from Conway's Law， i.e.：
Any organization that designs a system (in this case, a broader system, not just an information system) will necessarily produce a design whose structure is a copy of that organization's communication structure.
anBounded Context May map to a development team， So the discussionBounded Context Relationship between， It can also be seen as a discussion of the relationship between the team。 as to The way processes are integrated with each other， Whether introducingACL（ rot-proof layer） orOHS（ Open Hosting Services）， The aim is all to enable inter-process communication while， Better to doBounded Context Loose coupling between。 A microservice perspective， It is to meet the service boundary with sufficient autonomy。
So when DDD meets microservices, there are actually a lot of arcane parallels to be explored. It's not known that they might be able to collide with each other in an emotional way.
Recommended>>
1、Congratulations to Chengyang Hongdao plant has been rented
2、Zhongguancun No3 Primary Schools 2nd Technology Home Theme Technology Festival The Future Converge Here
3、IoT Big Data Blockchain together we open the age of intelligence
4、IBM unveils smaller than salt microcomputer will combine with blockchain to trace items in the future
5、If you want to push the limits of artificial intelligence study the human brain first