Domain Driven Design
@2x.png)
Bounded Contexts
A bounded context defines a boundary within which a particular domain model is valid. It’s a key DDD concept for dividing the domain into smaller, manageable parts.
@2x%20(1).png)
Context Mapping
Context mapping helps understand how different bounded contexts relate to each other and how different teams should interact.
@2x%20(2).png)
Patterns of context mapping
- Partnership: Two teams have cooperation and shared goals.
- Customer-Supplier: One team depends on another team’s services or APIs.
- Conformist: One team accepts the model of another without trying to adapt it.
Anti-Corruption Layer
A layer is implemented to translate between incompatible models used by different teams.
| When should use ACL | When should NOT use ACL |
|---|---|
| Country team business needs and domain model significantly different from the platform model. | Minimal differences in core models; maintaining ACL outweighs the benefits. Minor adjustments to the platform or local processes could be enough. |
| Local adaptation and compliance require ACL to serve as a buffer by adapting platform outputs to match local legal or operational requirements. | Short-term use for a project or interim solution — investing in ACL wastes resources. A lightweight integration or even manual workaround could be used. |
| If the platform is outdated or difficult to change, but the country team has no immediate option to replace it. ACL can help insulate the country team’s system from platform deficiencies. | |
| If the country team operates in a micro-service architecture and the platform is monolithic, or vice-versa — an ACL can become a bridge. |
Other Considerations
- Business processes and workflows
- Data mappings