Ddd boundaries & responsibilities
Download as PPTX, PDF•4 likes•1,217 views
The document discusses strategies for organizing complex domain models across teams and applications. It introduces the concept of bounded contexts to define the scope of individual domain models and establish consistency boundaries. Context maps are proposed to visualize the relationships between bounded contexts and identify points of integration. The document also discusses data ownership considerations, noting the tradeoffs between data duplication and integrity. Integrations strategies like shared kernels and anticorruption layers are presented to enable communication between bounded contexts while maintaining independence.
Ddd boundaries & responsibilities
- 1. Boundaries & Responsibilities: Teams, Apps, API and Data
- 2. Agenda • Strategic Design • Bounded Context and Context Maps • Integration Strategies & Recipes • Data Ownership • Integrity & Consistency • Duplication
- 3. Strategic Design Why? • Scaling up complex domain models • Total unification of the domain model for a large system will not be feasible or cost-effective • Modularity without losing benefits of integration
- 4. Design and Politics Often Intersect
- 5. Strategic Design What? • Need for a systematic, evolving design strategy • Doesn’t happen by itself or through good intentions • Proactive decisions about what should be unified • Pragmatic recognition of what’s not unified
- 6. Bounded Context • Defines the range of applicability of each domain model • Multiple models coexist and apply in different contexts • Defines consistency boundaries
- 8. Bounded Context Not Defined • Unclear in what context model should be applied • Unclear in what context model should not be applied • Lack of focus and confusion by issues outside
- 9. Bounded Context How? • Explicitly define a scope of a particular model • Explicitly set boundaries • Team organization • Usage within a specific application • Physical manifestation (codebase and DB schema)
- 10. Bounded Context Clarity & Freedom • Keep the model consistent within its bounds • Team responsible for the model deals with the whole lifecycle of each object, including persistence • Teams don’t get distracted or confused by issues outside
- 11. Recognizing Splinters Indicators • Confusion of domain language • Code interfaces don’t match up • Duplicate concepts • False cognates
- 12. Context Map • Project’s contexts • Relationships between contexts
- 13. Context Map • Identify each Model on the project • Define Bounded Context • Name each Bounded Context • Describe points of contact between models • Outline explicit translation • Highlight any sharing
- 14. Context Map Reflects: • Team structure • Management structure • Product strategy • Timelines • Trust • Physical office space
- 15. Context Map
- 16. MAP THE TERRAIN!
- 17. Context Map
- 18. Context Map • Bounded Contexts partition should be based on cost- benefit trade-off: • Independent team action • Direct and rich integration
- 19. Larger Bounded Context • Flow between user tasks is smoother (unified model) • Coherent and easy-to-understand model instead of two distinct ones plus mapping • Translation between two models can be difficult • Shared language fosters clear team communication
- 20. Smaller Bounded Context • Communication overhead between developers is reduced • Continuous integration is easier with smaller teams and code bases • Different models can cater to special needs • Ubiquitous language dialects can be encompassed by smaller models
- 21. Technical Considerations • Deployment • Versioning and backwards compatibility • Data migration • Environments
- 22. Integration Strategies and Recipes • Shared Kernel • Customer/Supplier • Conformist • Open Host • Published Language • Anticorruption Layer • Separate Ways
- 23. Integration Strategies and Recipes
- 24. DECISIONS ARE NOT IRREVERSIBLE
- 25. Data Ownership • Data Integrity • Data Duplication
- 26. Data Duplication Is data duplication BAD?
- 27. Data Duplication • Staleness • Inconsistency
- 28. Data Duplication The data may be stale… but is that really an issue?
- 29. Data Integrity • Different data has different requirements • Product Specifications • Product Assets • Product Pricing • Product Recommendations • Cost-benefit analysis
Editor's Notes
- #4: Monolithic all-encompassing domain model on one side of the spectrum (duplications, contradictions)Set of small, distinct sub-systems glued together with ad-hoc interfaces (lacks the power to solve enterprise-wide problems)
- #8: Metaphor:Cells can exist because their membranes define what is in and determine what can pass!
- #10: Don’t get distracted or confused by issues outside
- #11: BOUNDED CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
- #12: Litmus Paper Duplicate concepts: two model elements that represent the same conceptFalse cognates: two people who use the same term and think they are talking about the same thing, but they are not (less common, more insidiously harmful)
- #13: People on other teams won’t be aware of the CONTEXT bounds and will unknowingly make changes that blur the edges or complicate interconnections.
- #15: Overlap between project management and software design
- #17: MAP THE TERRAIN
- #18: SUBSTANCE OVER FORMWhatever forms the MAP takes it must be shared and understood by everyone on the projectMust provide clear name of each BC and must make points of contact and their nature clear
- #29: “We spend a great deal of effort maintaining data, maintaining integrity, maintainingconsistency, and some fool wants to duplicate this problem all over, now we have two lots of datato manage and synchronise!”The only issue that really exists is that this data could be stale or inconsistent – it may be 5seconds out of date, or 10 seconds, or maybe just 1 second – but this data may not be up to date.Well, of course it may not be up to date… but is any of the data in your system really up to date?Even if you just requested it from your Domain, and it appeared on screen, before you hit anykey on your keyboard, that data is already stale – by the time you press “update” someone orsomething else may have modified the data.Eventually the data may be up to date and consistent, it just may not be the instant you request it.So yes, the data may be stale, but is that really an issue? (hint: the answer is no)
- #30: “We spend a great deal of effort maintaining data, maintaining integrity, maintainingconsistency, and some fool wants to duplicate this problem all over, now we have two lots of datato manage and synchronise!”The only issue that really exists is that this data could be stale or inconsistent – it may be 5seconds out of date, or 10 seconds, or maybe just 1 second – but this data may not be up to date.Well, of course it may not be up to date… but is any of the data in your system really up to date?Even if you just requested it from your Domain, and it appeared on screen, before you hit anykey on your keyboard, that data is already stale – by the time you press “update” someone orsomething else may have modified the data.Eventually the data may be up to date and consistent, it just may not be the instant you request it.So yes, the data may be stale, but is that really an issue? (hint: the answer is no)