The document discusses the importance of context mapping in project success, detailing various relationship patterns between teams, such as partnership, customer/supplier, and separate ways. It explains how to create a context map to visualize inter-team communication, assess shared visions, and determine the suitability of Domain-Driven Design (DDD). Additionally, it provides definitions of key concepts like anti-corruption layers and open host services that facilitate integration between bounded contexts.

1. Stijn Volders
@ONE75
http://blog.one75.be

2. Context Mapping
Why a Context Map is essential for the success of your project
domaindriven.be – DDD Basics

3. What
• A simple diagram with Bounded Context’s who are involved in your
project an your relation with them

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

6. It’s all about relations

7. Relations fall into Patterns
• Partnership
• Customer/Supplier
• Big Ball of Mud
• Conformist
• Shared Kernel
• Separate Ways

8. All relations have their price

10. 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

11. Definition: Customer - Supplier
• 2 teams in an upstream/downstream relationship
• Upstream can succeed interdependently of the downstream team
• Downstream priorities factor into upstream planning

12. Definition: Big Ball of Mud
When you have to deal with a big, monolithic (legacy) system
• Often with large intermixed models

13. 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

14. Definition: Shared Kernel
Sharing a part of the model
• Very intimite interdependency
• Can leverage or undermine design work
• Must be kept small!

15. Definition: Separate Ways
Used to cut loose systems
• Integration is always expensive
• When there is little to zero interest/benefit in integration

16. 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

17. 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

18. Definition: Published Language
When you want a common language for translation between 2
bounded contexts
• Often combined with Open Host Service

19. Upstream/Downstream

20. Upstream/Downstream
• Not about the direction of the data!
• Upstream will influence downstream
• Might be technical (code)
• But also: schedule, responsiveness to external requests...

21. 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.

22. Let’s try it!

23. Domain: Amazon

24. Step 1
• Draw each Context with the name (as known in the UL)

25. Step 2
• Define which models communicate
• Bandwith

26. Step 3
• Indicate the direction of the relation, if applicable
(Upstream/Downstream)

27. Step 4
• Put the name of the Pattern on the relationship
• Partnership
• Customer/Supplier
• Conformist
• Separate Ways
• Big Ball of Mud
• Shared Kernel

28. Step 5
• Indicate which BC’s have explicit translation or sharing
• Anti Corruption Layer
• Open Host/Published Language

29. Questions?
Stijn Volders
@ONE75
http://blog.one75.be