One of the hardest problem when creating and developing microservices for an enterprise is their data. Analysing the business domain using Domain-Driven Design (DDD) and reason about what the data represents will help in achieving a microservices architecture, Christian Posta claims in one of a series of blog posts about microservices implementations.
For Posta, Principal Middleware Architect at Red Hat, the main reason for choosing a microservices architecture is that it enables teams to work on different parts of a system at different speed and with minimum interference between them. When organizing teams this way, the systems architecture will reflect it and evolve towards a microservices architecture.
The problem though, is to get this autonomy between teams really working and this is not trivial. Leaving the transactions and single database normally used in a monolithic application, for services with one database for each service can be a challenge, especially for traditional enterprises.
Posta notes that there is a huge difference between how internet companies and traditional enterprises implement microservices. While internet companies use microservices mainly for dealing with huge volume and scaling issues, traditional enterprise deal both with business and scaling complexity. The complexity in showing movies and posting tweets is far less than in an insurance claims system.
Building microservices for a reasonably complex enterprise domain, we need to find the boundaries between different responsibilities within that domain. In each of these boundaries we create a domain model, designed for and representing that responsibility. The data model for each boundary is then driven by the domain model in the same boundary. Using DDD we can find theses boundaries and create a bounded context for each, with each context becoming a microservice.
In Posta’s experience developers tend to build distributed systems assuming a single relational database, and try to abstract away the realities of unreliable networks. Often the problem with distributed data is solved using two-phase commits across multiple services. Instead Posta believes we have to look for transactional boundaries within each bounded context and find the smallest unit of atomicity needed to enforce business constraints and invariants, never allowing a transaction to spread to other contexts.
There is still a need for a service to inform other services what is happening and for this Posta recommends using events. One service publishes events about things happening in its domain and other services will read these events, adapt to their own models and persist any changes.
For a more in-depth description of these ideas, Posta refers to a series of blog posts by Vaughn Vernon describing aggregates, transaction boundaries and bounded contexts with a DDD mindset.
