DDD Strategic Design - Context Maps - Paulo Clavijo - April 2018
9 likes6,211 views
This document provides an introduction to context maps in domain-driven design. It discusses that while a single unified domain model is ideal, models typically fragment into multiple bounded contexts. Context maps identify each model and define the bounded context and points of contact between contexts. The document outlines several types of relationships between bounded contexts like shared kernel, customer/supplier, and anticorruption layer. It emphasizes that context maps should reflect the true practice of development teams.
DDD Strategic Design - Context Maps - Paulo Clavijo - April 2018
- 1. DDD Strategic Design Introduction to Context Maps Paulo Clavijo - April 2018DDD Guild - GSAD Dell-EMC
- 2. Domain-driven design - 10000 foot view
- 3. Strategic Design Ideally, it would be preferable to have a single, unified model. While this is a noble goal, in reality it typically fragments into multiple models. It is useful to recognize this fact of life and work with it. Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models. ● Context ● Distillation ● Large-Scale Structure
- 6. Problem Space vs Solution Space Sales domain Booking domain Marketing domain Problem Space (real world) Solution Space (domain model) design process Booking context Sales context Marketing context
- 7. Dom Ap ic o Ser s AP /In ef In as c e Dat e Architecture do mo s he t , al p en po n a d co sa f e c
- 8. Bounded Context Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied. Therefore: Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside. Domain-Driven Design, Eric Evans
- 9. Bounded Context Bounded Context gives team members a clear and shared understanding of what has to be consistent and what can develop independently Bounded Context Out of context Out of context Ubi o s L u g , un e an l om od Un e n u d o l
- 10. Bounded Context Large or complex models should be divided into bounded contexts where a model can be explicit by being understood in a specific context. customer message quote quote Sales context Booking context Marketing context notes customer address flight payment method newsletter customer loyalty booking paid flight cancelled booking
- 11. Big Ball of Mud Bounded Context
- 12. There is no direct one to one correlation between ● Domain - Context ● Context - Module ● Context - Micro-service Bounded Context
- 13. Context Map An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux. People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other. Therefore: Identify each model in play on the project and define its bounded context. This includes the implicit models of non-object-oriented subsystems. Name each bounded context, and make the names part of the ubiquitous language. Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain. Domain-Driven Design, Eric Evans
- 14. Context Map A model is valid in a specific context. Different context might need different version of the model, due to specific purposes. Define Bounded Contexts according to the way things are now. This is crucial. To be effective, the Context Map must reflect the true practice of the teams, not the ideal organization
- 15. Types of Bounded Context Relationships ● Shared Kernel ● Customer / Supplier ● Conformist ● Anticorruption Layer ● Separate Ways ● Open Host Service ● Published Language
- 16. Shared Kernel Two teams share a subset of the domain model including code and maybe the database. Teams involved must collaborate, any change in a kernel model must be done only in consultation with the other team. Payroll context employee Employee Management context Em oy o l
- 17. Customer / Supplier A Customer/Supplier or Consumer-Driven Contract relationship is where the downstream context defines the contract that they want the upstream context to provide. The two domains can still evolve independently, as long as the upstream context fulfills its obligations under the contract. The downstream team, considered as the customer, sometimes has veto rights. Team 1 Team 2
- 18. Conformist The downstream team conforms to the model of the upstream team. There is no translation of models and not vetoing. If the upstream model is a mess, it propagates to the downstream model. Team 1 Team 2 bar foo bar foo
- 19. Anticorruption Layer A layer that isolates a client's model from another's system model by translation. Team 1 Team 2 bar foo cat zoo ACL
- 20. Separate Ways There is no connection between the bounded contexts of a system. This allows teams to find their own solutions in their domain. Team 1 Team 2 pig zoo cat zoo
- 21. Open Host Service Each Bounded Context offers a defined set of services that expose functionality for other systems. Any downstream system can then implement their own integration. This is especially useful for integration requirements with many other systems. Team 1 Team 2 OHS
- 22. Published Language Similar to OHS. However it goes as far as to model a Domain as a common language between bounded contexts. Team 1 Team 2 PL Language
- 23. Context Map - Examples
- 24. Context Map - Examples
- 25. Communication between Bounded Contexts ● Interfaces beetween modules (monolith) ● RPC with SOAP ● REST ● Using Events
- 26. Transfering data between Bounded Contexts
- 27. References ● Domain-Driven Design. Eric Evans (2003). ● Domain-Driven Design Distilled. Vaughn Vernon (2016). ● Implementing Domain Driven Design. Vaughn Vernon (2013). ● The Anatomy Of Domain-Driven Design. Scott Millett and Samuel Knight. ● Domain Modeling Made Functional. Scott Wlashchin (2018).