在DDD中，上下文映射和有界上下文有什么区别？

Question

我刚开始学习DDD的概念，我不能理解一些东西。

上下文映射和有界上下文与SubDomain之间有什么区别？

如何识别有界语境之间的关系？

Answer 1

正如@Augusto提到的，这是蓝皮书中的几个章节，但如下所述。

域模型存在于业务规则和人们说话的方式中，但是在代码中捕捉到了它的简化。一定的命名是一致的，并在模型中强制执行必要的不变量。

有界上下文主要是概念性的(也可能是代码中的命名空间、模块、项目.)。它的意图是保持领域模型的一致性。因此，在上下文中，使用了一种普遍存在的语言。一个模型只需要满足这方面的需要。它是可以使用该模型的边界。在承认这些关系方面？有些可能是微妙的，但大多数不是。至少团队中的一些人会希望通过统一模型来“避免重复”。因此，这是一个明确的迹象，这是一种关系。名字通常是相同的或相似的..。或者可能是相同的，但是一个更适合于一个领域，另一个更适合于另一个域。

上下文映射更像是一个项目管理工具。它是一张地图，显示不同的上下文(以及内部的模型)之间是如何相互关联的。在电子商务系统中的订购域中，您可能有一个产品。这将导致许多复杂的尝试有一个统一的产品在一个模型，跨越订购，付款，内容的网站和库存领域(例如)。因此，每个域都应该有一个单独的模型。上下文映射是一个关系图和相关文档，它将这些有界的上下文联系在一起，因为随着订单在系统中的流动，数据从一个模型到另一个模型之间会有关系和转换。

您询问的最后一个元素是一个子域。这里您可能指的是泛型子域。就我个人而言，我觉得这个名字有点让人困惑。它使它看起来像是模型的一个子集。也许这是有意的，但我通常认为他们是他们自己的领域，只是一个不是核心的商业主张。例如，如果上述电子商务公司因同一天或第二天交货而闻名，那么他们可能不应该购买现成的库存和航运管理解决方案。另一方面，如果他们专注于一个只想要最便宜的交易，但不介意等待几天的市场，那么这将是一个通用子域的完美候选。

我的DDD词汇表在底部有很多链接，可以找到更详细的文章。

如果你是认真学习这门学科的，并且能找到一些书的话：

• 艾瑞克·埃文斯的领域驱动设计
• 用Vaughn Vernon实现领域驱动设计
• 域驱动的设计使斯科特瓦拉钦(我最喜欢的功能)

Answer 2

正如在评论中所说，这是一个广泛的主题，在DDD中非常重要。它是DDD的战略组成部分。无论如何，我会试着用一个整体的解释来回答你的问题：

DDD是关于理解和提炼我们想要解决的问题的领域。这是一个不断学习领域，与领域专家交谈的过程。所有的人(开发人员、商人等)都讲同一种语言。这种语言在任何地方都使用(会话、文档、源代码、.)。它被称为普适语言(UL)。

问题域可能有不同的功能领域，这也是域。它们是子域。因此，子域是问题域的子集。这就像将问题分解为较小的子问题，子域将是子问题的域。有3种子域：

• Core：精馏的目的是发现对业务有价值的子域，即将使您的产品比同类产品更好的子域。这样的子域就是“核心子域”。例如，在“项目管理”中，“任务分配”将是核心。
• 支持：它专门用于帮助核心功能的某些业务方面。例如，在“项目管理”中，有一个“日历”(用于标记任务交付日期)。
• 通用：任何类型的应用程序都可能需要的功能。例如，用户的身份验证和授权。

子域属于问题空间。

为了解决这个问题，您对子域进行建模，并创建有界上下文 (BCs)。在实践中，BC是一个自主的应用程序，包含子域的软件模型。公元前有自己的UL。它是UL的一个术语有意义的上下文。UL和BCs是DDD中最重要的部分。UL驱动BCs识别。

理想情况下，您应该将问题空间的子域与解决方案空间的BCs对齐，也就是说，每个子域应该有一个BC。

一个团队可以开发一个或多个BCs，但是BC应该由一个团队开发。

BCs属于解空间。

Context Map：这是一幅显示BCs及其之间关系的绘图。每一种关系都分为下列模式之一：

• 伙伴关系
• 共享内核
• 客户-供应商
• 墨守成规
• 反腐败层
• 开放主机服务
• 出版语言
• 分道
• 大泥球

认识到在关系中应用哪种模式，这将取决于您所拥有的特定情况。你必须考虑的一些事情是：

• 这两个小组一起协作。
• 其中一个队不关心另一个队。
• 团队可以谈判。
• 各队都是独立的。
• 对模型(上游)的更改会影响到另一个模型(下游)。