DDD：除电子商务样本外，如何将应用划分为有界上下文？

Question

我们在这里有一个非常大的应用程序，我考虑重新调整它以跟踪DDD人员的指导。

目前，它的第一个问题是有界上下文和上下文地图。也许我只是不喜欢它，但在我看来只是不可能做分裂。例如，我们在整个地方都有User对象，它与用户对象完全相同：显示名称，ID和角色。还有另一个例子：我们有CatalogItem对象来帮助我们对整个地方的其他实体进行分类。我们是否必须引入有界上下文依赖项？除了那些令人讨厌的电子商务样本之外，对此事有任何指导吗？

Answer 1

我发现，首先，有限的上下文和聚合根似乎是DDD中最简单的概念。直到您真正实现具有真实问题的DDD应用程序。这里没有简单的答案。它完全取决于您的业务需求（可伸缩性，可用性，延迟，一致性等）。 “正确”的解决方案是平衡这些问题以最适合您的需求的解决方案。

根据您提供的示例，有几个选择：

• 一个大的有界背景
• 使用重复数据（可能使用发布/订阅消息传递系统实现）分离有界上下文
• 将用户和CatalogItems拉入他们自己的有界上下文，让其他有界的上下文通过服务访问它们

要记住的一点是，查询需求通常与“编写”需求大不相同。它通常可以简化您的应用程序设计，使其具有单独的有界上下文，纯粹用于查询。如果这听起来可能适用，请查看CQRS。