meh*_*hdi 2 subdomain domain-driven-design bounded-contexts
我刚开始学习 DDD 概念，但我无法理解一些东西。
1-上下文映射与有界上下文和子域有什么区别？
2-如何识别限界上下文之间的关系？
正如@Augusto 提到的，这是蓝皮书中的几章，但这里是。
领域模型可以在业务规则和人们的交谈方式中找到，但它的简化是在代码中捕获的。某些命名是一致的，并且在模型中强制执行必要的不变量。
有界上下文主要是概念性的（也可能是代码中的命名空间、模块、项目......）。目的是保持领域模型内部的一致性。因此，在上下文中，使用了某种普遍存在的语言。模型只需要满足该上下文的需求。它是模型可以使用的边界。在认识这些关系方面？有些可能很微妙，但大多数则不然。至少团队中的一些人希望通过统一模型来“避免重复”……所以这清楚地表明存在某种关系。名称通常相同或相似...或者可能相同，但一个更适合一个域，另一个更适合另一个域。
上下文地图更像是一个项目管理工具。它是不同上下文（以及其中的模型）如何相互关联的地图。在电子商务系统的订购域中，您可能有一个产品。尝试在跨越订购、付款、 网站内容和库存域（例如）的模型中拥有统一的产品会导致很多复杂化。因此，每个领域都应该有一个单独的模型。上下文映射是将这些有界上下文关联在一起的图表和相关文档，因为当订单流经系统时，从一个模型到下一个模型之间会存在数据关系和转换。
您询问的最后一个元素是子域。这里您可能指的是通用子域。就我个人而言，我认为这个名字有点令人困惑。它使它看起来像是模型的子集。也许这是故意的，但我通常认为它们是他们自己的领域，只是一个不是业务主张核心的领域。例如，如果上述电子商务公司以当日或次日送达而闻名，那么他们可能不应该购买现成的库存和运输管理解决方案。另一方面，如果他们专注于一个只想要最便宜的交易但不介意等待几天的市场，那么这将是通用子域的完美候选者。
我的 DDD 术语表底部有很多指向更详细文章的链接。
如果您认真学习这门学科并且可以获得一些书籍：
正如评论中所说，这是一个广泛的主题，并且在 DDD 中非常重要。它是DDD的战略部分。无论如何，我会尝试通过整体解释来回答您的问题：
DDD 是关于理解和提炼我们想要解决的问题的领域。这是一个不断学习该领域、与领域专家交谈的过程。所有的人（开发人员、业务人员等）都说同一种语言。这种语言随处可见（对话、文档、源代码……）。它被称为通用语言（UL）。
问题域可能具有不同的功能区域，这些功能区域也可能是域。它们是子域。因此，子域是问题域的子集。这就像将问题分成更小的子问题，子域就是子问题的域。子域有3种：
核心：蒸馏的目的是发现对业务有价值的子域，即使您的产品比其他同类产品更好的子域。这样的子域就是“核心子域”。例如，在“项目管理”中，“任务分配”将是核心。
支持：专注于某些有助于核心功能的业务方面。例如，在“项目管理”中，有一个“日历”（用于标记任务交付日期）。
通用：任何类型的应用程序可能需要的功能。例如，用户的认证和授权。
子域属于问题空间。
为了解决这个问题，您需要对子域进行建模，并创建有界上下文(BC)。实际上，BC 是一个自治应用程序，包含子域的软件模型。BC 有自己的 UL。这是 UL 术语具有含义的上下文。UL 和 BC 是 DDD 中最重要的东西。UL 驱动 BC 识别。
理想情况下，您应该将问题空间的子域与解决方案空间的 BC 进行 1:1 对齐，即每个子域都应该有一个 BC。
一个团队可以开发一个或多个 BC，但一个 BC 只能由一个团队开发。
BC 属于解空间。
上下文图：它是显示 BC 以及它们之间的关系的图。每个关系都分为以下模式之一：
认识到在关系中应用哪种模式将取决于您的具体情况。您必须考虑的一些事情是：