Microservices is an approved architectural style making applications easier to develop, test, deploy, change and maintain. Therefore, FPT receives several requests to transform an existing monolithic application as well as design new application with this architectural style. Among different methodologies and best practices all around, Domain Driven Design helps the new architects and developers to have a good approach to start the project and design for the application fit with microservices architecture.
An introduction to Domain Driven Design
In the context of Microservice Architectures, a common question for the software developers is about defining the scope and size of each Microservice. Defining this boundary is not easy and if services are too fine-grained, they can share data across service boundaries or update in mass in response to a change in requirements. It makes services not fully autonomous as expected. Therefore, we have to understand the problem and domain that will be served by the microservice to define the right scope of the microservice. Domain-driven design (DDD) is created for struggling with the kind of domain complexity in designing microservices architecture. DDD is not a technology, rather it introduces terms, practices and principles to support decision making in complex business domains. If the complexity of the domain is not addressed early and properly within the application design, the best technology won’t help to create a system which is maintainable, extendable, etc. Further, DDD introduces a ubiquitous language which can collaborate the domain experts and software experts and map business domain concepts into software artifacts to take away the gap between people with different backgrounds and viewpoints. DDD defines a basis for how a model for a domain can be designed.
Domain Driven Design provides the guideline for strategic design and tactical design. Strategic design helps us to define what is strategically important to the business, how to divide the work by importance, and how to integrate the services. All the business functions and relationship among them are listed out with the collaboration between the software experts and domain experts to have a common understanding for all the functions. Next step is to define Bounded Context as a logical boundary within the domain based on the business’s department or work group divisions and the Context Map to display the interactions between these Bounded Contexts.
(Read more: CCTV System with the Power of Video Analytics in DX Era)
In the fine-grained tactical design phase, we can design the details of each bounded context including entities, aggregates, microservices, etc., how the microservices communicate with each other, how to implement generic business logic of application. The non-functional requirements for scalability, availability, security, team size, technology should also be considered to define the suitable scope and size of the microservice. After all consideration, the designed microservice will be reviewed and edited iteratively to ensure the default characteristics: single responsibility, no inter-dependencies, not many calls between services, loosely coupled and data consistency.
Domain Driven Design focuses on solving the complexity of business domain and does not specify any technology stack to implement these microservices. Therefore, after having a good design, the developers need a framework to successful deploy, operate and manage microservices with scalability, availability and automation lifecycle management. The common frameworks that we can use for microservices are Spring with Netflix OSS, Azure Service Fabric, Kubernetes, etc.
When to use Domain Driven Design
Domain Driven Design is not a silver bullet to design every application with microservices architecture. Applying the principles of DDD is hard and costly both in time and resource.
For generic or supporting subdomains, some domains or contexts may just contain data with little business logic. For these subdomains, keep things simple, straightforward, and uncomplicated by writing the working code quickly using CRUD and simple domain logic patterns. Modelling efforts should fully focus to the most important areas of the application: the core domain. It is useful for the complex or frequently changing business domain with a lot of correlated business rules.
In the journey of Digital Transformation for the multinational companies and for itself, FPT sees legacy enterprise systems under pressure to deliver new, differentiating digital services to customers with fast pace, scalability and availability. Redesign the system with microservices architecture with the help of Domain Driven Design and combine with other technologies such as containers, DevOps can dramatically speed time to market and help enterprises solving their legacy systems’ challenges in the emerging digital economy.
For more readings on related topics, please click here!
