Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Team relationships vs patterns. #19

Open
george-ka opened this issue Mar 2, 2024 · 1 comment
Open

Team relationships vs patterns. #19

george-ka opened this issue Mar 2, 2024 · 1 comment

Comments

@george-ka
Copy link

Could someone please explain better why the "Partnership" and "Customer-Supplier" are patterns and not team relationships? It seems like a mistake of categorization.
Even the explanation of these "patterns" begin with teams relationships.
If the aim of the repo is to simplify the understanding, I think it would be greate to either fix the categorization issue or explain why it was made this way.
I think Evanse's book is not a Bible and could tolerate new interpretations, doesn't it?

@skleanthous
Copy link

skleanthous commented Mar 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants