- WHAT IS DOMAIN DRIVEN DESIGN IN MICROSERVICES SOFTWARE
- WHAT IS DOMAIN DRIVEN DESIGN IN MICROSERVICES CODE
Again, the word consumable is of the utmost importance, as there are several factors that make an API consumable versus non-consumable. In the current digital era, most of the consumers are of latter type, thus a microservice should provide a cohesive business functionality exposed as consumable APIs. If the consumer is a human, a GUI is a preferred interaction mechanism, whereas if the consumer is a software, an API route is preferred. Microservices capability exposed for consumption via APIsĪn external consumer has multiple ways to interact with the microservice. There is a lot of literature already published on microservices architecture, so I’ll not dwell further into it. Since each microservice embeds the technical architecture within the bounded context, any service may evolve in any way necessary. Physical separation is expected for each service, allowing easy replacement and evolution. The technical architecture is embedded within the domain parts, honoring DDD’s bounded context principle by making each service physically separate, which leads to ‘a share nothing’ architecture norm from the technical perspective. One of the key principles of the microservices style of architecture is strict partitioning across domain-bounded contexts. Referring back to our XYZ hotel chain illustration-įollowing the principles of microservices, each domain constructs a microservice. For example, every 2+2 expression is a not a microservice.
WHAT IS DOMAIN DRIVEN DESIGN IN MICROSERVICES CODE
Remember: Not each and every function defined in your code base is a microservice, unless it is solving the domain’s requirements aligned to business goals. The physically bounded context in microservices correlates exactly to the concept of architectural quantum - it is a physically decoupled, deployable component with highly functional cohesion, yet nimble enough to evolve quickly.
To identify and define business domains, please refer to "How to start with Domain Driven Design" from the previous article.
WHAT IS DOMAIN DRIVEN DESIGN IN MICROSERVICES SOFTWARE
Thus, we should always build software in the bounded context of a business domain. That means no matter how hard we try to detach software development from business, it is very challenging to completely isolate them. Microservices are built on Conway’s law that says - "Any organization that designs a system (defined more broadly than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure". In this article, we’ll talk about how it enables articulation of microservices. In the previous article, we talked about Domain-Driven-Design (DDD), and how it can help define a bounded context. Domain-Driven-Design in action - Microservices