战略DDD：系统中隐藏的动态上下文关系

想想您当前的系统。一开始可能很简单 - 白板上有几个干净的方框、清晰的沟通渠道、明确的界限。然后现实开始显现。出现了新的要求。团队发生了变化。最初的清晰结构演变成更……有趣的东西。

通过本系列，我们发现这种演变并非随机的。它遵循一些模式——有些是故意的，有些是自然发生的，但都揭示了我们的系统在现实世界中是如何运作的。

战略DDD设计中模式语言

1、权力动态：谁领导，谁跟随？
我们首先探索影响和控制所定义的关系：

1. 上游/下游：当一个上下文需要引导而其他上下文需要跟随时。想想您的核心域服务如何影响系统的其他部分。它们就像建筑物的地基 - 其他一切都取决于它们是否坚如磐石。
2. 客户-供应商：上游/下游的成熟发展，我们学会了添加服务协议和明确期望。当团队意识到他们需要的不仅仅是技术集成时，他们还需要组织协调，这就是发生的事情。
3. 伙伴关系：不同环境之间的平等协作。这种做法在实践中很少见，但一旦奏效，就会发挥巨大作用。我曾见过这种做法在订单处理和库存系统之间取得了辉煌的成功，而这两个系统都无法真正领导或跟随。

2、整合范围
然后我们发现了上下文如何在保持其身份的同时协同工作：

1. 顺从者：有时阻力最小的道路就是正确的道路。为什么要与有效的模式作斗争？我见过一些团队浪费了数月时间试图独树一帜，而顺从对他们来说可能更有利。
2. 防腐层：我们模式的外交官。令人惊讶的是，一个位置合适的翻译层往往可以防止不同领域模型之间爆发全面战争。
3. 开放主机服务：“好邻居”模式。当您的环境需要为许多其他环境提供服务时，标准化总是胜过定制化。

3、使用同一种语言
沟通模式变得至关重要：

1. 已发布的语言：创建每个人都同意的共享词汇表。这不仅与数据格式有关 - 还与跨团队建立理解有关。
2. 共享内核：“共同点”模式。但要小心 - 如果不警惕，看似有用的共享可能会变成痛苦的耦合。

自由模式
最后，我们探索了一种独立的模式：

1. 分道扬镳：有时最好的整合就是没有整合。我见过一些团队通过分道扬镳取得的成果比他们试图强行合作取得的成果更多。

当然，我们还有一个警示故事：

1. 大泥球：没人想要但似乎每个人都会遇到的模式。了解我们是如何走到这一步的，是避免它的第一步。

现实检验
以下是使用这些模式给我带来的教训：

1. 上下文Context驱动一切
   • 团队活力比技术纯度更重要
   • 组织结构对架构的影响比我们承认的要大
   • 有时“错误”的模式恰恰适合你的情况