3

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?

Keith Pinson
  • 7,835
  • 7
  • 61
  • 104
Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47

3 Answers3

5

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.

JefClaes
  • 3,275
  • 21
  • 23
4

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.

Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
1

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.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • That part I get it. But they have three tables referring allegedly to the same "person". Let's say that each department starts modifying those three tables independently. Isn't that a chaos? My question I guess is how can I use ONE reference to that person regardless of how BC look at it? – Pepito Fernandez Jul 29 '13 at 05:57
  • 3
    BCs should not share any data. You can't have multiple BCs looking at the same table. In that case you just havr one BC. BCs can publish events to notify other BCs about changes but those events should bot contain data, just IDs. So Sales can notify CRM that client 5232 has been added and client 973 has been made a preferred customer. – Steven Jul 29 '13 at 06:34
  • 1
    And if no data is shared, those three tables can evolve independently. – Steven Jul 29 '13 at 06:35
  • @Steven but isn't a database integration just an implementation of strongly consistent integration between bounded contexts? I mean, if you have 1 table, which contains shared identity field (for example, AccountId); than if you create Account in 1st BC, then you will get that Account automatically in 2nd BC without event integration, but because of database integration – ajukraine Jul 21 '17 at 16:29