Component patterns

Another strategy for decomposing our components with proper boundaries is based on applying the component patterns. Chapter 3, Foundation Patterns, will cover the patterns that provide the mechanisms used by all components, whereas Chapter 4, Boundary Patterns, and Chapter 5, Control Patterns both contain patterns that pertain to specific flavors of components. The boundary patterns, such as Backend For Frontend and External Service Gateway, interact with external entities at the edge of the system, while the control patterns, such as Event Orchestration, deal with mediating, choreographing, and orchestrating the interactions between components.

Continuing our bounded context example, the Customer Self-Service and Catalog contexts focus on interacting with different user groups. As such, they would each follow the Backend For Frontend pattern. Let's say that SalesForce and ZenDesk fulfill the Sales Contexts and Support Contexts, respectively. This would indicate that each should have an External Service Gateway component that acts as an anti-corruption layer to adapt and integrate those systems. All inter-component communication and collaboration is achieved using events. When there are relatively few events and the business processes are straightforward, it is reasonable for the components to apply the Event Collaboration pattern and know about the event types of the other components specifically. However, as these processes become more complicated it is good to add in components in the middle that act as mediators, following the Event Orchestration pattern, to maintain loose coupling between the participating components.