In this week’s podcast, Thomas Betts talks with Chris Richardson, a developer, architect, Java Champion and author of POJOs in Action. Before his workshop on Microservices w/ Spring Boot and Docker at QCon San Francisco 2016, Richardson took time to discuss his ideas on how to use DDD and CQRS concepts as a guide for implementing a robust microservices architecture. You can also watch his related presentation “Developing Microservices with Aggregates”.
Key Takeaways
- "Microservice architecture" is a better term than "microservices". The latter suggests that a single microservice is somehow interesting
- The concepts discussed in Domain-Driven Design are an excellent guide for how to implement a microservices architecture
- Bounded Contexts correspond well to individual microservices
- Event sourcing and CQRS provide patterns for how to implement loosely coupled services
- When converting a monolith to microservices, avoid a big bang rewrite, in favor of an iterative approach
Subscribe on:
Show Notes
Microservices vs. Microservices Architecture
- 1m:50s - @crichardson tweet: "Microservice architecture" is a better term than "microservices". The latter suggests that a single microservice is somehow interesting.
System Decomposition Following Domain-Driven Design
- 4m:16s - Decomposing a system into a set of microservices is related to understanding business capability and subdomain.
- 5m:16s - If you decompose your system in the wrong way, you’re making a mistake at an architectural level. The worst case is a distributed monolith.
- 6m:34s - In DDD terms, each service is itself a bounded context, with its own domain model and ubiquitous language.
- 8m:33s - The “fuzzy stuff” in the DDD book, such as bounded contexts, directly apply to a microservices architecture.
- 10m:26s - One DDD constraint is that a transaction can only create or update a single aggregate. In practice, this means microservice architectures cannot have distributed transactions.
- 11m:13s - If you want to do microservices properly, read the DDD book.
Microservice Boundaries, EDA and CQRS
- 11m:51s - Microservices must be loosely coupled, usually creating a model with one database per service.
- 12m:45s - There is a business requirement to maintain data consistency across services, and using an event driven architecture is a good way to achieve that.
- 13m:38s - Event sourcing is specific technique for persisting domain objects as a series of events.
- 14m:11s - Just as transactions don’t like to be split across microservices, queries cannot simply join across multiple data sources. CQRS provides a solution that accommodates querying via microservices and materialized views.
Replacing a Monolith
- 17m:27s - Microservices are not a silver bullet, nor a free lunch. MSA comes with complexity, ranging from data management to deployment.
- 20m:00s - When does it make sense to make the transition from a monolith to an MSA?
- 20m:35s - MSA is a solution to a problem. With an existing monolith, if are you unhappy with the rate of development, or the pain associated with making changes, then microservices are probably the solution.
- 22m:29s - When moving to microservices, definitely do not do a big bang rewrite -- take an iterative approach, incrementally refactoring your monolith into a set of services.
- 24m:16s - Implementing microservices can utilize new, cool technology, but always remember the purpose of writing an application is to automate critical business processes. Domain-Driven Design can help develop the business logic at the core of your system.
Technology Concepts Discussed
- Microservices
- Command Query Responsibility Segregation (CQRS)
- Domain-Driven Design (DDD)
- Event Driven Architecture
Books Mentioned
