Team relationships vs patterns.

[ddd-crew]

Team relationships vs patterns.

[skleanthous]

Speaking about how I understand those: these patterns are patterns of relationship between Bounded Contexts and relate to the model being implemented or used by the team. The team relationship, ie how the different teams work together to deliver on work within those BC's is something slightly different (and described above the context map patterns). The team relationship should be informed from the desired BC pattern used (and \ or vice versa depending on the approach taken), and this can be used as a heuristic to form team relationships.

So for example, a Partnership pattern would benefit strongly from recognising a Mutually Dependent team relationship. On the other hand if you modeled a partnership between two BC's but the teams are not speaking together (and as such aren't in a mutually dependent relationship), you should probably do something, as this can lead to problems. Things aren't always so clear-cut though and real team relationships are way too complex to fit neatly into 3 categories (especially as broad as these ones), but they are good heuristics and starting points.

Re the commend about Evan's book not being a bible: absolutely! In this case I think there was the issue of naming the actual team relationships, ie how people work together, and the patterns inside a model with BC's with their relationships. I think Evans didn't want to overload the term relationship here and just used the term to describe the human kind of relationship instead of the model one and used the word pattern for that.