Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DDD Basics - Context mapping


Published on

A Context Map will visualize your system: cluttered models, too much or not enough communication, dependencies on other systems are just some of the insights you'll gain if your start using them

Published in: Software, Technology, Business
  • Be the first to comment

DDD Basics - Context mapping

  1. 1. Stijn Volders @ONE75
  2. 2. Context Mapping Why a Context Map is essential for the success of your project – DDD Basics
  3. 3. What • A simple diagram with Bounded Context’s who are involved in your project an your relation with them
  4. 4. Why • Get insight in inter-team communication an their bandwith • Measure to which extent a vision could be shared • Help to decide if DDD is appropriate
  5. 5. It’s all about relations
  6. 6. Relations fall into Patterns • Partnership • Customer/Supplier • Big Ball of Mud • Conformist • Shared Kernel • Separate Ways
  7. 7. All relations have their price
  8. 8. Definition: Partnership When teams in 2 contexts succeed or fail together • Co-ordintad planning of development and joint management of integration • Interdependent features should be scheduled so that they are completed for the same release
  9. 9. Definition: Customer - Supplier • 2 teams in an upstream/downstream relationship • Upstream can succeed interdependently of the downstream team • Downstream priorities factor into upstream planning
  10. 10. Definition: Big Ball of Mud When you have to deal with a big, monolithic (legacy) system • Often with large intermixed models
  11. 11. Definition: Conformist • 2 teams in an upstream/downstream relationship • Upstream has no motivation to provide for the downstream team’s needs • Downstream team doesn’t put effort in translation
  12. 12. Definition: Shared Kernel Sharing a part of the model • Very intimite interdependency • Can leverage or undermine design work • Must be kept small!
  13. 13. Definition: Separate Ways Used to cut loose systems • Integration is always expensive • When there is little to zero interest/benefit in integration
  14. 14. Definition: Anticorruption Layer • Isolating layer to limit impact of changes in an upstream system • Requires little or no modification to the upstream system • Translates in both directions between the 2 models
  15. 15. Definition: Open Host Service When you want to open your system for integration • Protocol that gives access to your system as a set of services • Open for everyone that needs to integrate with your system • New services can be added on request but need to serve a “general” purpose
  16. 16. Definition: Published Language When you want a common language for translation between 2 bounded contexts • Often combined with Open Host Service
  17. 17. Upstream/Downstream
  18. 18. Upstream/Downstream • Not about the direction of the data! • Upstream will influence downstream • Might be technical (code) • But also: schedule, responsiveness to external requests...
  19. 19. Attention! • Map the current situation, not the (desired) future • If it’s a mess, show it. It’ll bring focus to the problems & risks involved in your project.
  20. 20. Let’s try it!
  21. 21. Domain: Amazon
  22. 22. Step 1 • Draw each Context with the name (as known in the UL)
  23. 23. Step 2 • Define which models communicate • Bandwith
  24. 24. Step 3 • Indicate the direction of the relation, if applicable (Upstream/Downstream)
  25. 25. Step 4 • Put the name of the Pattern on the relationship • Partnership • Customer/Supplier • Conformist • Separate Ways • Big Ball of Mud • Shared Kernel
  26. 26. Step 5 • Indicate which BC’s have explicit translation or sharing • Anti Corruption Layer • Open Host/Published Language
  27. 27. Questions? Stijn Volders @ONE75