domain-driven-design - DDD : How to divide application to Bounded Contexts besides e-commerce sample?

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




我们这里有一个相当大的应用程序，我考虑对它进行一点重构，以遵循 DDD 人员的指导。

目前，它的首要问题是有界上下文和上下文映射。也许我只是不理解它，但在我看来，做除法是不可能的。例如，我们到处都有 User 对象，它是完全相同的 User 对象:显示名称、id 和角色。还有另一个例子:我们有 CatalogItem 对象来帮助我们对整个地方的另一个实体进行分类。我们是否必须引入限界上下文依赖项？除了那个烦人的电子商务样本之外，还有没有针对这件事的任何指导？

Answer 1

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

对于您给出的示例，有几个选择:

一个大型有界上下文

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

将用户和目录项拉入它们自己的有界上下文中，并让其他有界上下文通过服务访问它们

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