我们在这里有一个很大的应用,我考虑重构它一点点跟踪DDD的指导.
现在的第一个问题是边界上下文和上下文映射.也许我只是不喜欢它,但在我看来,只是不可能做分裂.例如,我们在整个地方都有User对象,它与User对象完全相同：display name,id和roles.还有另一个例子：我们有CatalogItem对象来帮助我们对整个地方的其他实体进行分类.我们必须引入有界的上下文相关性吗？除了这个令人讨厌的电子商务样本之外,还有什么指导吗？
我发现,起初,有界的上下文和聚合根似乎是DDD中最简单的概念.这是直到你真正实现一个具有真实世界问题的DDD应用程序.这里没有简单的答案.它完全取决于您的业务需求(可扩展性,可用性,延迟,一致性等). “正确”的解决方案是平衡这些关切,以最符合您的需求.
以你给出的例子,有几个选择：
>一个大有界的上下文
>使用重复的数据(可能使用发布/订阅消息传递系统实现)分开有界的上下文
>将用户和CatalogItem拉入自己的有界环境,并通过服务让其他有限的上下文访问它们
需要注意的是,查询需求通常与“写”需求非常不同.它可以经常简化您的应用程序设计,使单独的有限的上下文纯粹用于查询.如果这听起来像可能适用,请查看CQRS.
