Microservices: Domain Driven Design

How do we introduce microservices to a team that has always had one large application?

We could follow the following strategy, called Domain Driven Design. The benefit of DDD is that we can start delivering benefits of microservices fast, without waiting for the entire model to get developed (Big Bang approach).

  • First we need to describe the current system as a monolithic app that needs to be broken down into microservices.
  • For this we need to first describe current concerns with the old system
  • Then we would describe business capabilities that the old system serves

At this point we prepare to loosely couple the services that the old system offers.

Visual approach helps here – we draws service boundaries, and we use business needs as a driver. This will represent a view of each entity from different perspectives, and there could be overlap: some entities can be used in both contexts. In such case we assign only one domain as an owner.

We draw bounded contexts around the business areas, we list entities, and we prepare for the hidden and shared modeling.
What we need to do is to prepare to share the models between contexts – yet we cannot allow to tie two contexts together, for example by publishing state changes so that these events can be used to rebuild the state of the model in another bounded context. The rest of the model should be hidden from external contexts as we want to avoid coupling them together.

Quick note about the best practices.

Microservices are small autonomous services, which require to be:

  1. Modeled around business concepts
  2. Require culture of automation
  3. Deployed independently
  4. To hide internal implementation details
  5. Failures to be isolated
  6. Should be highly observable
  7. Architecturally we want to decentralize all logic and services, so things like God-service that centrally drives the rest should be avoided at all costs.
  8. It’s way better to delegate some brain function to every service, and keep them cohesive, doing the teamwork
  9. Lastly, to achieve the above, it’s preferred to keep Dev teams independent.