Downloaded 10 times
DDD Domain Relationships Radars
- 1.
- 2. Ex : Imaginea 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. Ex : VisualStudio 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. Ex : Imagineyou 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. Ex : Workslike 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. Inner Source Ex: Thesame 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. Ex : Duringthe 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. Ex : Thinkof 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. Ex : Youknow 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. Ex : Servicearchitecture 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. Ex : aDatabase 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. Credits, Thanks andAcknowledgments • 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 pixabay.com 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