如何表示有界上下文？

Question

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

有关边界上下文之间如何交互的问题？

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

- Arnis Lapsa

---

你可以看一下http://msdn.microsoft.com/en-us/magazine/dd419654.aspx。它在讨论“不可变性”。 - LCJ

Answer 1

我想说“这要看情况”。 有时将BC实体映射到同一个数据库中可能足够，而有时对于BC来说，您可能需要不同的数据库。 在我看来，电子商务可能更像是一个BC而不是一个完整的领域。 我在一个批发代理商那里花了太多时间，他们销售食品产品。 因此，领域是“批发”，而绑定的上下文是库存、采购、销售、发票、产品目录和电子商务（也许我在这里使用了错误的英语措辞）。 这些BC都知道“产品”，但它们都有不同的产品视图。 例如，采购可能会有一个附有供应商信息、采购价格等信息的产品实体。 而电子商务领域中的产品将从客户角度建模，它将具有对于查看它的客户相关的信息，包括特定价格等信息。 电子商务BC会从多个来源获取其产品信息；产品目录和销售。 其中基本信息来自产品目录，客户特定价格来自销售。 因此，电子商务BC中的产品存储库可以通过一些服务进行上下文映射（最可能是Web或WCF），以构建我们的电子商务产品实体）。 就个人而言，我会将此建模为单独的程序集，我会有一个电子商务模型和一个销售模型。 我的大多数电子商务模型信息将来自外部来源，并且不会在本地持久化。 只有像购物车这样的东西才是本地持久的，因为这些对象由电子商务模型拥有。 一旦客户尝试完成购买，我将从购物车构建一个预订单，然后将其传递给销售BC。 通过直接服务调用或通过消息队列传递。 总之，我倾向于围绕特定的BC构建我的系统，并仅通过服务与其他BC交互。 我知道很多人将其BC放置在同一个程序集中，并从同一应用程序中使用多个BC等。 但是，我觉得让一个特定目的的应用程序了解多个上下文很奇怪。我更倾向于只在一个上下文中传递所需数据，并将其传递给其他应用程序。

- Roger Johansson

Answer 2

我完全同意一切都取决于具体情况，但是仍有一些应该遵循的指导原则。界限上下文的目的就是建立边界。引入精确定义的契约（接口）来分隔应用程序的不同部分。

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

希望这可以帮助你。

- Szymon Pobiega