Microservice boundary definition dilemma
Defining the boundary of services is inevitable regarding microservice architecture design. How micro does a service have to be to be considered a microservice? What are the ideal boundaries of services that can meet changing business requirements? What are the differences between SOA and microservices?
Many engineers claim that they work on microservices but apply the SOA approach.
Service-oriented Architecture(SOA) VS Microservice
SOA focuses on service reusability and resolves the information silos issue.
Microservices emphasized higher service granularity, service decoupling, and scalability.
From the above definition, it is evident that SOA has a more coarse-grained service partitioning compared to microservice.
Oversized services inevitably introduce certain redundancy, relatively poorer resource isolation, and loses some of the microservice’s benefits, while over-decomposed services bring service governance and operational difficulties. Imagine the nightmare of managing thousands of microservices for the latter case.
Therefore, we will need an approach to define the boundaries, modeling and etc.
What is the problem with starting with data modeling?
A physical data model is a database-specific model that represents relational data objects. It couples with requirements. Requirements changes would cause data model changes, and the internet industry is rapidly iterating. We can expect that physical data models are no longer suitable for the business workflow if they are unthoughtfully defined. We will need something more conceptual, like context boundary, architecture design, specification, etc.
So, what approach can help us to design microservice architecture?
Define the domain model, divide the domain boundary, and then carry out the micro definition of microservices according to the outcome. As a result, the business and technical boundaries are reasonable, achieving high cohesion and loose coupling, which is the ideal state of microservices.
DDD is the formula to achieve the above outcome.
What is Domain Driven Design(DDD)?
Domain Driven Design(DDD) is an effective software design approach focusing on modeling software based on business-expert-defined business domains.
While it brings a great benefit to our software design, it has certain difficulties to implement it.
Before jumping into how to do it, the following sections will elaborate on what is required to apply the approach, why it is hard to implement it, and common mistakes we need to avoid.
What is required to apply DDD?
The crucial components in DDD are business models. Defining ideal business models requires us to have an in-depth understanding of our businesses. It brings difficulties to implement it.
Why are the difficulties to implement DDD?
- It requires architects to have rich experience in business domains and related techs.
- Architects from other industries might not be able to define proper domain models.
- It requires each role in the team to have a considerable degree of professionalism to implement it.
- Tech experts must be able to assist architects in completing the logical design phase; otherwise, the project will stall.
- To implement it, all parties, including technical managers, technical experts, and developers from various levels, must be able to understand well-defined diagrams, such as conceptual diagrams.
If the project doesn’t have a particular volume and the company’s business model doesn’t have a robust business model, practicing such a design would lengthen the entire development cycle. This is because completing the holistic design following the approach consumes an obnoxious amount of time. The early conceptual design and the logical design phases are time-consuming. Many companies, especially startups, do not resources(e.g. time, experts, etc) to follow a standardized approach like this. Even worse, some startups’ core business domain varies frequently over time, and it will cost more resources to make adjustments.
However, it is still valuable to integrate multiple software design methods and DDD to formulate a design approach suitable for the scenarios of your projects and to construct solutions for complex business requirements. I am going to elaborate on how we do it later. Let’s start with some basic concepts.
Three phases to practice DDD
- Conceptual design (scope definition)
- From stages between 1 to 3 in the above diagram, architects, product managers/owners, and operations staff work together to produce concept diagrams, concept classes, domain class diagrams, etc.
- Logical Design
- Senior devs(e.g., tech lead, tech experts, senior developers, core developers, etc.) work with architects to do modeling according to the first step’s outputs. These outputs are business-modeling-related documentation and diagrams, such as use case diagrams, use case specifications, use case scenarios, use case views， business object models, etc.
- Physical Design
- Developers work together to implement the requirements. They fix some emerging issues that they haven’t considered in previous steps. For example, some performance issues might require them to adjust models.
- Developers and architects decide how to store data(e.g., indexing, read-write segregation, partitions, etc.).
- Developers and architects define architecture software architecture styles(e.g., microservice, RESTful architecture, etc.)
- We will know whether our models are suitable for microservice or not till this point.
Conclusion
We’ve looked at why we need DDD and three major phases in this blog article. In my next post, I will explain how DDD helps us to determine business domain and model boundaries, basic concepts of strategic design, and why copying models online or similar business is not a good idea.
Adrian's Blog 
2 thoughts on “DDD(Domain Driven Design)-1 Apply DDD to design microservice architectures that genuinely satisfy our business evolution needs”