迁移到有界上下文

Question

我目前有一个Web API项目，目前在同一个解决方案中处理所有系统。我将其分解为单独的解决方案，以便它们可以独立运行（例如Azure WebJob），因为如果后端中的某些内容发生更改，我不想重新部署Web项目。

我的问题在于，即使我将逻辑分开，它们也被单个上下文捆绑在一起，这样如果我在一个中进行更改，我将不得不重新部署所有，因为迁移不会匹配。

这就是为什么我一直在关注Bounded Context和DDD。我正在研究如何解决这个问题，但却无法理解关系的运作方式。

很多网站都是管理网站（即创建实体，没有实际处理），因此会围绕此分割上下文：

1. 用户添加并维护货币转换率（这是两个实体） 总）。
2. 用户添加并维护有关如何处理付款的详细信息（请注意，这不是处理付款，它只包含有关paypal帐户详细信息的信息等）。

所以我把这个背景分开了，这听起来是否合理（还有很多像税范，收费结构等）？

如果这是要走的路，我该如何处理这两种情境之间的关系？举个例子：

1. 付款方式需要指向“有效”的链接。货币转换。我知道我可以将其作为ID，但我需要检查它的状态，因此需要访问该模型。
2. 货币换算只能设为＆＃39;非活动＆＃39;如果目前没有使用它的付款方式。同样，这需要访问其他模型。

因此逻辑上模型需要相互访问，如何将其包含在上下文中？我可以在不同的上下文中为模型添加导航属性吗？或者我应该将其作为单独的DbSet添加，并可能使用视图进行映射？

由于

Answer 1

  

所以我正在分裂上下文，听起来是这样   合理的开始（有更多像税，如税   频带，电荷结构等）？

• “因此，它们可以独立运行和部署”可能不足以说明何时应该拆分有界上下文。这解决了解决方案空间的一个方面，但是如果你在问题空间看不够好，那么BC和子域之间的错位会导致很多摩擦。您可能最终总是将一组看似无关的“可独立部署的单元”部署在一起，因为您没有意识到他们谈论同样的事情。

  识别子域名是蒸馏您的业务的产物 - 将大功能区域分开并定义哪些部分是您的核心域以及哪些是辅助活动。每个子域都有自己的特定语义（Ubiquitous Language）。在您的情况下，正如评论中指出的那样，Currency Conversion和Payment Methods可能是同一子域（付款？）的一部分。它并不自动意味着它们也应该在同一个BC中，但它可能是good idea以保持子域与BC的一对一对齐，因为额外的BC是有代价的。

  回到可部署性，即使它可以是有界上下文的一个有益效果，但就独立的部署单元而言，它们并不总是那么容易翻译。上下文映射模式（共享内核，客户供应商等）和BC通信通常可以导致模型，因此代码库的一部分由多个BC共享。出现了代码和API同步问题，这些问题可以质疑简单的“可部署的免费电子”视图。

• 仅仅因为你使用Bounded Context方法并不意味着你必须在每个BC中使用DDD的战术模式（聚合根，不变量等）。使用它们应该是一个有根据的决定，以解决问题空间可管理性的解决方案空间复杂性。如果“货币转换只能设置为无效...”是与您的业务中的付款方式和货币管理相关的唯一规则，则可能不值得为该有界上下文提供完整的富域模型。 CRUD可能更适合那里。