Bounded Contexts in DDD with CQRS. Sharing Aggrega

问题:

I found this code sample.

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.

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

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.

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.

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?

回答1:

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

Here is an alternative..

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.

回答2:

Generally reuse across contexts isn't encouraged. There may be rare cases where a shared kernel could help, but usually domain objects (and aggregates thereof) should be kept local to their respective context. Otherwise you'd introduce tight coupling and lose one of the main advantages of bounded contexts. They won't be able to change and evolve independently of eachother.

回答3:

Bounded contexts will often be implemented by different teams and for different customers (in the example the Sales department and Customer relations department). They will both have their own view on a customer and I think the project is trying to exaggerate that point by naming them differently.