Sam Newman (2016), Building Microservices, O′Reilly.
Eric Evans (2003), Domain-driven design, Addison-Wesley.
Services should have the following qualities:
- Loose coupling: a change to one service should not require a change to another.
- High cohesion: we want to find boundaries within our problem domain to help ensure the related behavior is in one place.
Bounded Context
Rewording Evans (2003) definition of a bounded context: any given domain consists of multiple bounded contexts, and residing within each are models that do not need to be communicated outside. Each bounded context has an expicit interface, where it decides what models to share with other contexts.
In other terms (Klepl”a specific responsibility enforced by explicit boundaries”. If you want information from a bounded context, or want to make requests of functionality within a bounded context, you communicate with its explicit boundaries.
Modules and Services
By thinking clearly about what models should be shared, and not sharing out internal representations, we avoid tight coupling. We have aslo identifie a boundary within our domain where all like-minded business capabilities should live, giving us high cohesion.
Once you have found your bounded contexts in your domain, make sure they are modeled within your codebase as modules, with shared and hidden models.