Boundaries & Responsibilities: Teams, Apps, API and Data
Agenda• Strategic Design• Bounded Context and Context Maps• Integration Strategies & Recipes• Data Ownership   • Integrity...
Strategic DesignWhy?• Scaling up complex domain models• Total unification of the domain model for a large system  will not...
Design and Politics Often Intersect
Strategic DesignWhat?• Need for a systematic, evolving design strategy• Doesn’t happen by itself or through good intention...
Bounded Context• Defines the range of applicability of each domain model• Multiple models coexist and apply in different c...
Bounded Context
Bounded Context Not Defined• Unclear in what context model should be applied• Unclear in what context model should not be ...
Bounded ContextHow?• Explicitly define a scope of a particular model• Explicitly set boundaries   • Team organization   • ...
Bounded ContextClarity & Freedom• Keep the model consistent within its bounds• Team responsible for the model deals with t...
Recognizing SplintersIndicators• Confusion of domain language• Code interfaces don’t match up• Duplicate concepts• False c...
Context Map• Project’s contexts• Relationships between contexts
Context Map• Identify each Model on the project• Define Bounded Context• Name each Bounded Context• Describe points of con...
Context MapReflects:• Team structure• Management structure• Product strategy• Timelines• Trust• Physical office space
Context Map
MAP THE TERRAIN!
Context Map
Context Map• Bounded Contexts partition should be based on cost-  benefit trade-off:   • Independent team action   • Direc...
Larger Bounded Context• Flow between user tasks is smoother (unified model)• Coherent and easy-to-understand model instead...
Smaller Bounded Context• Communication overhead between developers is  reduced• Continuous integration is easier with smal...
Technical Considerations• Deployment• Versioning and backwards compatibility• Data migration• Environments
Integration Strategies and Recipes• Shared Kernel• Customer/Supplier• Conformist• Open Host• Published Language• Anticorru...
Integration Strategies and Recipes
DECISIONS ARE NOT  IRREVERSIBLE
Data Ownership• Data Integrity• Data Duplication
Data Duplication           Is data duplication BAD?
Data Duplication• Staleness• Inconsistency
Data Duplication         The data may be stale…        but is that really an issue?
Data Integrity• Different data has different requirements   • Product Specifications   • Product Assets   • Product Pricin...
Upcoming SlideShare
Loading in …5
×

Ddd boundaries & responsibilities

860 views
706 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
860
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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)
  • Metaphor:Cells can exist because their membranes define what is in and determine what can pass!
  • Don’t get distracted or confused by issues outside
  • BOUNDED CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
  • 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)
  • People on other teams won’t be aware of the CONTEXT bounds and will unknowingly make changes that blur the edges or complicate interconnections.
  • Overlap between project management and software design
  • MAP THE TERRAIN
  • 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
  • “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)
  • “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)
  • Ddd boundaries & responsibilities

    1. 1. Boundaries & Responsibilities: Teams, Apps, API and Data
    2. 2. Agenda• Strategic Design• Bounded Context and Context Maps• Integration Strategies & Recipes• Data Ownership • Integrity & Consistency • Duplication
    3. 3. Strategic DesignWhy?• 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. 4. Design and Politics Often Intersect
    5. 5. Strategic DesignWhat?• 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. 6. Bounded Context• Defines the range of applicability of each domain model• Multiple models coexist and apply in different contexts• Defines consistency boundaries
    7. 7. Bounded Context
    8. 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. 9. Bounded ContextHow?• 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. 10. Bounded ContextClarity & 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. 11. Recognizing SplintersIndicators• Confusion of domain language• Code interfaces don’t match up• Duplicate concepts• False cognates
    12. 12. Context Map• Project’s contexts• Relationships between contexts
    13. 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. 14. Context MapReflects:• Team structure• Management structure• Product strategy• Timelines• Trust• Physical office space
    15. 15. Context Map
    16. 16. MAP THE TERRAIN!
    17. 17. Context Map
    18. 18. Context Map• Bounded Contexts partition should be based on cost- benefit trade-off: • Independent team action • Direct and rich integration
    19. 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. 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. 21. Technical Considerations• Deployment• Versioning and backwards compatibility• Data migration• Environments
    22. 22. Integration Strategies and Recipes• Shared Kernel• Customer/Supplier• Conformist• Open Host• Published Language• Anticorruption Layer• Separate Ways
    23. 23. Integration Strategies and Recipes
    24. 24. DECISIONS ARE NOT IRREVERSIBLE
    25. 25. Data Ownership• Data Integrity• Data Duplication
    26. 26. Data Duplication Is data duplication BAD?
    27. 27. Data Duplication• Staleness• Inconsistency
    28. 28. Data Duplication The data may be stale… but is that really an issue?
    29. 29. Data Integrity• Different data has different requirements • Product Specifications • Product Assets • Product Pricing • Product Recommendations• Cost-benefit analysis

    ×