Pep*_*dez 4 .net domain-driven-design cqrs bounded-contexts
我找到了这个代码示例.
https://code.google.com/p/ddd-cqrs-sample/
似乎非常完整和井井有条.不是"框架",只是一个具有非常精细和明确的方式来做事情的示例项目.但是,不完整.这带来了一些疑问.
他们擅长回答你的问题.通过https://groups.google.com/forum/#!forum/ddd-cqrs-sample查看他们的Google论坛
好.事实是,他们在SALES BC中拥有客户,在CRM BC中拥有客户/潜在客户.我想我们都同意指向同一个"人".假设在销售漏斗中,该人员作为潜在客户开始,然后通过购买使他成为客户的东西成为客户.
我的问题是,为什么他们有三个分离代表同一个"人"？难道不能像"共享内核聚合"吗？我不知道这样的事情是否存在.有点困扰我在数据库Client/Customer/Leads中有三个表用于相同的"东西".此外,在示例中还不清楚(CRM未实施)您如何在BC之间进行通信.我阅读了他们的文档,但我找不到任何有价值的线索.
这个过程怎么样？假设您需要为此潜在客户/客户/客户添加一个地址来发送订单.你会选哪一个？我想在Shipping BC的ShippingAddress？用Id指向？顾客？客户？您应该直接将地址添加到客户吗？例如直邮,因为它与Shipping没有任何关系？
共享内核在CRM和Sales BC之间引入了非常紧密的耦合.
这是另一种选择..
CRM BC 拥有客户.您不必在Sales BC中复制完整的客户AR.这避免了必须处理双向同步.您可以使Sales BC中的Client AR通过其标识符引用CRM BC中的Customer AR,然后将特定的Client属性封装在Sales BC中.这在Sales和CRM BC之间创建了一致性或客户 - 供应商关系,其中Sales BC位于下游,CRM BC位于上游.CRM上下文可能会使用开放主机服务来使客户AR可用于销售BC.
通常不鼓励跨上下文重用.可能在极少数情况下共享内核可以提供帮助,但通常域对象(及其聚合)应保持在其各自上下文的本地.否则你会引入紧耦合并失去有界上下文的一个主要优点.他们将无法独立改变和发展.
| 归档时间： |
|
| 查看次数： |
1790 次 |
| 最近记录： |