Limited contexts in DDD with CQRS. Sharing aggregates / objects. Possible?

Question

I found this sample code.

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

It seems very complete and well organized. Not a wireframe, just a sample project with very detailed and explicit ways to do something. BUT incomplete. And this raises some doubts.

They answer questions well. Check your google group at https://groups.google.com/forum/#!forum/ddd-cqrs-sample

OK The fact is that they have a client in SALES BC and a client / leader in CRM BC. I think we all agree, pointing to the same "person." Let me say that in the sales sequence a person begins as a Lead, then becomes a Client, buying something that makes him a Client.

My question is: why do they have three divisions of the representation of the same "person"? Doesn't that look like a “cumulative aggregate core”? I do not know if such a thing exists. It bothers me a bit to have three tables in the Client / Customer / Leads database for the same “thing”. The plus in this example is not clear (CRM is not implemented) how you communicate between BC. I read their documentation, but I could not find any valuable information about this.

How will this process be? Let me say that you need to add this Lead / Customer / Client address to send the order. Which one would you choose? I assume that ShippingAddress is in Shipping BC? With an identifier indicating? Customer? Customer? Should I add the address directly to the client? For example, for direct mail, since it has nothing to do with delivery?

Answer 1

The collaborative core introduces a very tight connection between CRM and Sales BC.

Here is an alternative ..

CRM BC owns customers. You do not have to duplicate the full AR client in Sales BC. This avoids two-way synchronization. You can make client AR in the BC sales database a CR reference in CRM BC with your identifier, and then save the specific Client properties encapsulated in Sales BC. This creates a conformist or customer relationship between Sales and CRM BC, where Sales BC is downstream and CRM BC upstream. The CRM context is likely to use the open host service to make the client AR available to Sales BC.

Answer 2

In general, reusing contexts is not recommended. There may be rare cases where a collaborative kernel might help, but usually domain objects (and their aggregates) should be local in the appropriate context. Otherwise, you introduce a hard link and lose one of the main advantages of a limited context. They will not be able to change and develop independently of each other.

Answer 3

Limited contexts will often be performed by different teams and for different customers (for example, in the sales department and customer departments). Both of them will have their own idea of ​​the client, and I think that the project is trying to exaggerate this point, calling them differently.