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 Domain Relationships Radars


Published on

DDD Domain Relationships can seem very abstract at first. Here are Radars that you can use in Event Storming sessions to present the relationships to your attendees in a digestible way

Published in: Software
  • Be the first to comment

  • Be the first to like this

DDD Domain Relationships Radars

  1. 1. DDD Domain Relationship Radars Philippe Bourgau
  2. 2. Ex : Imagine a startup building a system. It can become large without any thought for architecture. That’s when you get a big ball of mud. When you have to deal with big, monolithic (legacy) system • Often with large intermixed models Big Ball of Mud
  3. 3. Ex : Visual Studio and Office teams and products contain similar features, but they are coded twice to let the 2 products evolve independently. Used to cut loose systems • Integration is always expensive • When there is little to zero interest / benefit in integration Separate Ways
  4. 4. Ex : Imagine you are using Rails or a clone to build a web app. Rails comes with a built in ORM that makes accessing the DB really simple. You’ll just have to use the ORM objects in your domain layer. • 2 teams in upstream / downstream relationship • Upstream has no motivation to provide for the downstream team’s needs • Downstream team doesn’t put efforts in translation Conformist
  5. 5. Ex : Works like a third-party provider. Send a request to the provider, and they’ll get back to you. • 2 teams in an upstream / downstream relationship • Upstream (supplier) can succeed independently of the downstream team (customer) • Downstream priorities factor into upstream planning Customer Supplier
  6. 6. Inner Source Ex: The same techniques used to collaborate in the open source world can be used internally. Inner source can be useful to mitigate the need for co-ordinated planning. But committing changes to complex functional aspect of other domains is tricky.
  7. 7. Ex : During the PI planning, teams can collaborate together to build a larger feature. They need to synchronize a lot. When in 2 contexts succeed or fail together • Co-ordinated planning of development and joint management of integration • Interdependent features should be scheduled so that they are completed for the same release Partnership
  8. 8. Ex : Think of how your objects interact with generic language collections. You are often expected to write comparision operators. This small part is a shared kernel. Sharing a part of the model • Very intimate interdependency • Can leverage or undermine design work • Must be kept small ! Shared Kernel
  9. 9. Ex : You know the moto “always wrap your 3rd parties”. That avoids getting stuck with a provider and helps to migrate to new versions. • Isolating layer to limit impact of changes in upstream system • Requires little or no modification to the upstream system • Translates in both directions between the 2 models Anti Corruption Layer
  10. 10. Ex : Service architecture enables devops team to build and run their own sub-system independently. APIs enforce a clear separation of responsabilities in the code. 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 Open host Service
  11. 11. Ex : a Database is an open host service that exposes SQL as a powerful API. When you want a common language for translation between 2 bounded contexts • Often combined with Open Host Service Published Language
  12. 12. Credits, Thanks and Acknowledgments • This was greatly inspired from Alberto Brandolini's presentation Context Mapping in Action • Most of the illustrations come directly from Eric Evans' Domain Driven Design, Tackling Complexity in the Heart of Software book • Missing illustration came from and from the classic Big Ball of Mud article • Descriptions where inspired from Stijn Volders' presentation DDD Basics – Context Mapping • Finally, thanks to my colleagues at Murex