Collaboration models

We often default to one way of collaborating without thinking about alternatives or trade offs. Specifically, at Microsoft, we tend toward partnership, with consensus being expected for decisions at every level of granularity. That can feel equitable and good, but it also incurs high coordination costs. Other options are possible:

• Partnership: Two way communication, two groups come to a consensus about changes and each modify their own area.
• Shared kernel: Two groups can modify a shared thing, as long as they take responsibility for not breaking things for the other group.
• Customer-supplier: One group defines things and the other takes what it gets.
• Open-host: One group defines things but takes responsibility for creating a “public” face, making it a reasonable standard for other groups.
• Separate ways: No integration between groups; the groups agree to duplicate functionality if needed.

Open questions:

• When do we recommend using each of these?
• What does it look like?

References

Khononov, Vladik. Learning Domain-Driven Design . 1st edition, O’Reilly Media, Inc., 2021.

Bounded contexts are collections of one or more subdomains, worked on by a single team and unified by a common language. It’s best practice to start out with large contexts and divide as needed. Its size is a function of the model it encompasses, rather than a goal itself. They should not be junk drawers nor jacks of all trades.

There are three patterns of collaboration between contexts: 1. Cooperation A. Partnership: Two way communication, ad-hoc informing each other, two way interpretation of a point of connection B. Shared kernel: Use when one thing has to be implemented in two different bounded contexts. Each team can modify it and has to work with everything in both bounded contexts. Limit this pattern because any change cascades quickly. 2. Customer-supplier A. Conformist: The downstream context has to work with what the upstream team gives it. Use when the upstream context has more power. B. Anti-corruption layer: The downstream context can’t use information from the upstream context directly, and creates a layer to transform it into something it can use. Use when the upstream context has more power. C. Open-host service: The upstream context provides a “public” face that downstream contexts can come get what they need from. This interface doesn’t conform to the host context’s ubiquitous language. 3. Separate ways: No integration, each context duplicates the functionality they need. Use when the benefits of coordination are outweighed by the difficulties of communication. Usually for generic subdomains that are easily handled in a couple of different ways. Do not use for core subdomains.