问团队组成DDD

EN

DDD是关于设计的。因此，它不一定是决定团队的主要来源。然而，当涉及到有界上下文时，DDD可以与团队结构相关。

有界上下文本身独立于团队结构。它对应于较大域模型/子域的某些部分。但是，边界的设定方式意味着，在同一环境中的人之间的互动/交流/团队合作要多于与外部人的互动/交流/团队合作。这就使得与组织团队相关的有界上下文。

在这方面，Evans (DDD的“发明者”)以BC驱动的团队结构(例如合作伙伴关系、客户/供应商开发、Conformist，特别提到团队关系)讨论了一些上下文映射技术。

因此，认为每个团队管理一组有限制的上下文似乎是合理的。甚至可以与其他领域驱动的方法(如流行的基于子域的微业务分割模式或微锋 )产生协同作用。

我建议您看看团队拓扑和组织拓扑。

与克里斯多夫一样，您可以使用有限制的上下文并形成团队拓扑所称的复杂子系统团队或启用团队。

然而，将团队与有限的上下文相结合可能不是最好的解决方案，因为它很好地阻止了您实现与流一致的团队。一个与流相一致的团队专注于某个特定的客户或用户群体，这些客户或用户能够深入了解这些涉众，而这种深入的理解将帮助他们为产品提供有用的、有价值的更改。

我会小心使用DDD来定义团队。定义流之间的潜在依赖关系或突出显示启用团队或复杂的子系统团队可能有用的地方可能更有用。然而，我的经验告诉我，与流相一致的团队通常是一个很好的选择，这些团队将跨越多个有限制的上下文。