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

我们在这里有一个非常大的应用程序,我考虑稍微重构一下,以跟踪DDD人员的指导.

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

我发现,起初,有界的上下文和聚合根似乎是DDD中最简单的概念.直到您真正实现具有真实问题的DDD应用程序.这里没有简单的答案.它完全取决于您的业务需求(可伸缩性,可用性,延迟,一致性等)."正确"的解决方案是平衡这些问题以最适合您的需求的解决方案.

通过您给出的示例,有几个选择:

一个大的有界背景

使用重复数据(可能使用发布/订阅消息传递系统实现)分离有界上下文

将Users和CatalogItems拉入他们自己的有界上下文,并让其他有界上下文通过服务访问它们

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