具有CQRS的DDD中的有界上下文。共享聚合/实体。可能？ [英] Bounded Contexts in DDD with CQRS. Sharing Aggregates/Entities. Possible?

问题描述

我找到了此代码示例。

https://code.google.com/p/ddd-cqrs-sample/

似乎非常完整且井井有条。这不是一个框架，而只是一个示例项目，它具有非常精细和明确的处理方式。但是，不完整。这会带来一些疑问。

Seems very complete and well organized. Not a "framework", just a sample project with a very granular and explicit ways to do things. BUT, incomplete. And this brings some doubts.

他们擅长回答您的问题。在 https://groups.google.com/forum/上查看其Google网上论坛。 ＃！forum / ddd-cqrs-sample

They are good at answering questions thou. Check their google group at https://groups.google.com/forum/#!forum/ddd-cqrs-sample

确定。事实是他们在SALES BC中有客户，在CRM BC中有客户/领导。我认为我们都同意指向同一个人。假设在销售渠道中，此人以潜在客户开始，然后通过购买使他成为客户的东西成为客户。

OK. Thing is that they have Client in the SALES BC and Customer/Leads in the CRM BC. I think we all agree is pointing at the same "person". Let's say that in the sales funnel, the person starts as a Lead, then becomes a Customer by Purchasing something making him into a Client.

我的问题是，为什么他们有一个人的三个单独的代表？难道就不像共享内核集合？我不知道这样的事情是否存在。在数据库客户 /客户 /客户中具有相同的事物的三个表有点困扰我。在示例中加号尚不清楚（未实施CRM）如何在BC之间进行通信。我阅读了他们的文档，但找不到任何有价值的线索。

My question is, Why do they have three separates representation of the same "person"? Couldn't it be like a "Shared Kernel Aggregate"? I don't know if such a thing exist. It kinda bothers me a little bit to have three tables in the database Client/Customer/Leads for the same "thing". Plus in the example is not clear (CRM is not implemented) how you communicate among BC. I read their documentation but I couldn't find any valuable clues about it.

该过程如何？假设您需要向该潜在客户/客户/客户添加地址以发送订单。您会选择哪一个？我猜在不列颠哥伦比亚省的ShippingAddress吗？指向一个ID？顾客？客户？您是否应该将地址直接添加到客户？例如，对于直接邮件，由于与运输无关？

How would that process be? Let's say that you need to add this Lead/Customer/Client an address to ship the order. Which one would you pick? I guess ShippingAddress in the Shipping BC? With a Id pointing to? Customer? Client? Should you add the address directly to Customer? For direct mail for example, since it has nothing to do with Shipping?

推荐答案

共享内核引入了很多 CRM和Sales BC之间的紧密耦合。

A shared kernel introduces very tight coupling between the CRM and Sales BC.

这里是另一种选择。

CRM BC 拥有个客户。您不必一定要在Sales BC中复制完整的客户AR。这避免了必须处理双向同步。您可以使Sales BC中的客户AR通过其标识符引用CRM BC中的Customer AR，然后将特定的Client属性封装在Sales BC中。这将在Sales和CRM BC之间建立一致或客户-供应商关系，其中Sales BC在下游，而CRM BC在上游。 CRM上下文可能会使用开放主机服务，以使客户AR对销售BC可用。

The CRM BC owns customers. You don't necesarrily have to duplicate the complete customer AR in the Sales BC. This avoids having to deal with two-way synchronization. You could make the Client AR in the Sales BC reference the Customer AR in the CRM BC by its identifier, and then keep the specific Client properties encapsulated in the Sales BC. This creates a conformist or customer-supplier relation between the Sales and CRM BC, where the Sales BC is downstream and the CRM BC upstream. The CRM context will probably use an open-host service to make the Customer AR available to the Sales BC.

这篇关于具有CQRS的DDD中的有界上下文。共享聚合/实体。可能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！