9 Microservice Architecture and Domain Driven Design
This chapter covers
- Domain driven design
- Why domain driven design is a valuable tool to analyze microservices
- Subdomain analysis
- Bounded Contexts and Entities
In the last chapter we discussed how WartMart bought Fantlers, and now Bullwinkle is the CEO of the Fantlers division of WartMart. Which is fine, except now we have to make all our microservices fit inside the WartMart systems. To deal with all of the point-to-point integrations needed at big companies like WartMart, we considered the Canonical Model pattern. It works great to reduce the number of integrations we need to make. Unfortunately, the enterprise Canonical Model fails when combined with microservice design, because it forces us to create a huge enterprise-wide model, which is very hard to evolve and change. This is the exact opposite of what we are trying to achieve with microservice design. A good microservice architecture is isolated, cohesive and loosely coupled.
So we have a big problem when we have a lot of applications in a company that have to work together. We have a solution for this problem, that helps reduce the integration points. Unfortunately, this solution creates a huge creaky model that becomes almost impossible to change or evolve. This is a big problem and Eric Evans, a product owner and software architect who was designing systems for large conglomerates like WartMart, was one of the people who was losing sleep over it.