答案 0 :(得分：12)
我会说'这取决于'
有时候将BC实体映射到同一个数据库可能就足够了，有时候你的BC可能有不同的数据库。
IMO，电子商务可能更像是一个BC而不是一个完整的域。
我在一个销售食品的销售代理商上花了太多时间。
所以域名是“整体销售”，有限的背景是，库存，购买，销售，发票，产品目录和电子商务（也许我在这里使用错误的英文措辞）
这些BC中的每一个都知道“产品”，但他们都对产品有不同的看法。
e.g。购买可能有一个产品实体，附有供应商信息，购买价格等。
虽然电子商务领域的产品将从客户的角度进行建模，但它会提供与客户相关的信息，其具体价格等。
电子商务BC将从多个来源获得其产品信息;产品目录和销售。 其中基本信息来自产品目录，客户特定价格来自销售。因此，BC电子商务中的产品库可能会从其他BC（通过某种服务，在我的案例中很可能是web或wcf）进行上下文映射，以构建我们的电子商务产品实体。
我个人将其建模为单独的程序集，我会有一个电子商务模型和销售模型。
我的电子商务模式中的大多数信息都来自外部来源，并且不会在本地持久存在。 只有购物车才能在本地持久存在，因为这些对象归电子商务模式所有。
一旦客户尝试完成购买，我将从购物车构建预订，然后将其传递给销售BC。 通过直接服务呼叫或通过消息队列。
简而言之，我倾向于围绕特定的BC构建我的系统，并且只通过服务与其他BC进行交互。
我知道很多人确实将他们的BC放在相同的程序集中并使用来自同一个应用程序的多个BC。 但我发现奇怪为什么一个特定用途的应用程序应该知道多个上下文。 我宁愿只知道一个上下文，然后将我需要的任何数据传递给其他应用程序。
答案 1 :(得分：6)
我当然同意这一切都取决于，但有一些指导方针可以/应该遵循。有界上下文的目的是边界。通过引入明确定义的合同（接口）将应用程序的一部分与另一个分开的边界。
我倾向于将BCs视为SOA中的服务。对我而言，理想情况下它们是物理上独立的应用程序（OS进程/ IIS网站）。二进制当然也是分开的。 BC之间的所有通信都是理想的异步。在现实世界中，这几乎是不可能的，但至少我不允许跨BC交易，因为它们是纯粹的邪恶。
希望有所帮助。