3

One suggested way to model entity identities in a domain model is to create value objects instead of using primitive types (f.e. in C#):

public class CustomerId
{
  public long Id { get; set; }
}

In my opinion this classes should be used throughout the whole application and not only in the domain model. Together with commands and events they can define a service contract for a bounded context. Now in an message/event driven architecture with multiple bounded contexts and each having a separate service contract it is easy to run into circle dependencies.

In the communication between bounded contexts you will have adapters and translators and usually most properties will be crunched into local values. But how to deal with identities of aggregate roots living in other bounded contexts? One solution to this problem is to create local context sibling classes for identity classes of foreign (remote) entities. But this violates somehow the DRY principle. An other approach could be to place the contracts for all bounded contexts in one assembly. I've seen this in many CQRS examples and in my opinion this is code smell. As a last solutions one can decompose the identity classes back to primitive types in all contracts (events and commands) and let each bounded context compose back his local identity classes (if needed) in the domain model. But this could lead to wrong identity compositions on compound identities (f.e. UserId+TenantId).

How do you deal in your projects with identity sharing across bounded context boundaries?

Sebastian
  • 443
  • 3
  • 9

1 Answers1

2

What will you do if your Customer in one context has a different name in other contexts, say Lead in sales or Receipient in shipping?

If they each have a CustomerId then it defies the purpose of one context's concepts and language not leaking into other contexts.

Don't get me wrong, I'm totally in favor of encapsulating the aggregate ids in a value object. But every context should have their own respective implementations with their names as in each context's ubiquitous language.

Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
  • Point taken, this is quite a good answer. In my opinion this is a **must have** when the same entity lives in both contexts (but with one master and maybe different properties) and is synchronized somehow downstream. – Sebastian Jul 04 '14 at 09:09
  • But there are a lot of situations where it makes no sense to artificially enrich the ubiquitous language of a domain with new role-based names just to hold an foreign reference. On the other hand dealing in a front end or integration layer with different type names for (implicit) the same concept can be quite awkward. It is important to remember that in the one context the type (encapsulating **the same** primitive value) is called _CustomerId_ and in the other context it is called the _ReceipientId_. This implicit knowledge must be made somehow explicit, maybe with an interop-translator. – Sebastian Jul 04 '14 at 09:09
  • @Sebastian exactly, and that's the very purpose of the *Context Map*. An often overlooked but still useful tool described in DDD. – Dennis Traub Jul 04 '14 at 14:30