Decomposition pattern by bounded context

There are three steps to apply the decomposition pattern by bounded context: first, identify the domain, which is what an organization does. Then identify the subdomain, which is to split intertwined models into logically-separated subdomains according to their actual functionality. Finally, find the bounded context to mark off where the meaning of every term used by the domain model is well understood. Bounded context does not necessarily fall within only a single subdomain. The three steps are as follows:

The benefits of this pattern are as follows:

• Use of Ubiquitous Language where you work with domain experts, which helps with wider communication.
• Teams own, deploy, and maintain services, giving them flexibility and a deeper understanding within their bounded context. This is good because services within it are most likely to talk to each other.
• The domain is understood by the team with a representative domain expert. There is an interface that abstracts away of a lot of the implementation details for other teams.

There are a few drawbacks as well:

• It needs domain expertise.
• It is iterative and needs to be continuous integration (CI) to be in place.

• Overly complex for a simple domain, dependent on Ubiquitous Language and domain expert.
• If a polyglot approach was used, it's possible no one knows the tech stack any more. Luckily, microservices should be smaller and simpler, so these can be rewritten.

More details can be found in the following books:

• Building-microservices, Sam Newman (2015)
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans (2003)
• Implementing Domain-Driven Design, Vaughn Vernon (2013)