c# - 如何表示有界上下文？

Question

我的意思是 - 物理上，在代码中。命名、命名空间、文件夹、程序集、数据库的组织。

有界上下文应该如何交互？

例如，随意使用经典的电子商务业务领域。

Answer 1

我会说“这取决于”

有时将您的 BC 实体映射到同一个数据库可能就足够了，有时您的 BC 可能有不同的数据库。

IMO，电子商务可能更像是一个 BC，而不是一个完整的域。

我在一家销售食品的整体销售代理处花了太多时间。

所以域是“整体销售”，而有界上下文是库存、采购、销售、发票、产品目录和电子商务（也许我在这里使用了错误的英文措辞）

这些 BC 中的每一个都知道“产品”，但他们对产品都有不同的看法。

例如，Purchase 可能有一个带有供应商信息、购买价格等的产品实体。

虽然电子商务领域的产品将从客户的角度进行建模，但它会包含与查看它的客户相关的信息、他们的具体价格等。

电子商务 BC 将从多个来源获取其产品信息；产品目录和销售。其中基本信息来自产品目录，客户特定价格来自销售。

因此，电子商务 BC 中的产品存储库可能会从其他 BC 进行上下文映射（通过某种服务，在我的情况下很可能是 web 或 wcf）来构建我们的电子商务产品实体）

我个人将其建模为单独的组件，我将有一个电子商务模型和一个销售模型。

我的电子商务模型中的大部分信息都来自外部来源，不会在本地持久存在。只有像购物车这样的东西才会在本地持久化，因为这些对象归电子商务模型所有。

一旦客户尝试完成购买，我会从购物车中构建一个预订单，然后将其传递给销售 BC。通过直接服务调用或通过消息队列。

所以简而言之，我倾向于围绕特定的 BC 构建我的系统，并且只通过服务与其他 BC 交互。

我知道很多人确实将他们的 BC 放在同一个程序集中并使用来自同一个应用程序的多个 BC 等。但我只是觉得奇怪为什么一个用于特定目的的应用程序应该知道多个上下文。我宁愿让它只知道一个上下文，然后将我需要的任何数据传递给其他应用程序。

Answer 2

我当然同意这一切都取决于，但有一些可以/应该遵循的指导方针。有界上下文的目的是边界。通过引入明确定义的合同（接口）将应用程序的一部分与另一个应用程序分开的边界。

我倾向于将 BC 视为 SOA 中的服务。对我来说，这意味着理想情况下它们是物理上独立的应用程序（操作系统进程/IIS 网站）。二进制文件当然也是分开的。理想情况下，BC 之间的所有通信都是异步的。在现实世界中这几乎是不可能的，但至少我不允许跨 BC 交易，因为它们是纯粹的邪恶。

希望有帮助。