Arn*_*psa 13 c# domain-driven-design bounded-contexts
我的意思是 - 在物理上,在代码中.组织命名,命名空间,文件夹,程序集,数据库.
有限的上下文应该如何互动？
例如,随意使用经典的电子商务业务领域.
Rog*_*son 12
我会说'这取决于'
有时候将BC实体映射到同一个数据库可能已经足够了,有时候你的BC可能有不同的数据库.
IMO,电子商务可能更像是一个BC而不是一个完整的域.
我花了一点时间在一个销售食品的销售代理商那里.
因此,域名是"整体销售",有限的背景是,库存,购买,销售,发票,产品目录和电子商务(也许我在这里使用错误的英文措辞)
这些BC中的每一个都知道"产品",但他们都对产品有不同的看法.
例如,购买可能有一个产品实体,其上附有供应商信息,购买价格等.
虽然电子商务领域的产品将从客户的角度进行建模,但它将具有与查看它的客户相关的信息,其具体价格等.
电子商务BC将从多个来源获得其产品信息; 产品目录和销售.基本信息来自产品目录,客户特定价格来自销售.
因此,BC电子商务中的产品存储库可能会从其他BC(通过某种服务,在我的情况下很可能是web或wcf)进行上下文映射,以构建我们的电子商务产品实体)
我个人将其建模为单独的程序集,我会有一个电子商务模型和销售模型.
我的电子商务模型中的大部分信息都来自外部资源,并且不会在本地持久存在.只有像购物车这样的东西才会在本地持久存在,因为这些对象归电子商务模式所有.
一旦客户试图完成他们的购买,我将从购物车构建预订,然后将其传递给销售BC.通过直接服务调用或通过消息队列.
简而言之,我倾向于围绕特定的BC构建我的系统,并且只通过服务与其他BC进行交互.
我知道很多人确实将他们的BC放在相同的程序集中并使用同一个应用程序中的多个BC等.但我发现为什么特定用途的应用程序应该知道多个上下文的原因很奇怪.我宁愿只知道一个上下文,然后将我需要的任何数据传递给其他应用程序.
我当然同意这一切都取决于,但有一些指导方针可以/应该遵循.有界上下文的目的是边界.通过引入明确定义的合同(接口)将应用程序的一部分与另一个分离的边界.
我倾向于将BCs视为SOA中的服务.对我而言,理想情况下它们是物理上独立的应用程序(OS进程/ IIS网站).二进制当然也是分开的.BC之间的所有通信都是理想的异步.在现实世界中,这几乎是不可能的,但至少我不允许跨BC交易,因为它们是纯粹的邪恶.
希望有所帮助.