Re: IDs in the domain

I don't think you should reference whole objects inside an aggregate if all you need is an identifier. Especially when that reference encompasses multiple aggregates.

I understand your concern when it comes to the UL. But there's no need to call them {whatever}Id, you can just use a term that's part of the UL instead. That object then happens to contain all the fields required to enforce the business rules. Which in case of having to uniquely identify an entity might happen to be just a simple Guid.

Am 11.05.2013 um 18:17 schrieb "Michael" <[email protected]>:

> Hello everyone,
> 
> I'm reading my way through Vaughn Vernon's "Implementing DDD" and I'm currently half-way through. I like the general approach, however, there's a thing that bothers me: the code is teeming with IDs. TenantId, userId, whateverId.
> 
> IDs such as these don't have a place in the ubiquitous language of a bounded context and I really don't want to deal with them in code implementing the domain logic.
> 
> In my view, using IDs there amounts to an ill-encapsulated, manually-managed de/serialization strategy. The IDs are only stand-ins for proper objects, so why not handle the conversion at the boundary and then work with domain objects throughout the domain code?
> 
> Put slightly differently, when I hold an entity, there's no need for a conceptually separate ID. An entity is identical only to itself and as such is its own identity. IDs only come into it if an entity needs a shortcut to represent it outside of its original context.
> 
> So, are there common opinions or even a consensus on IDs among DDD practitioners? Is the approach in IDDD representative?
> 
> Michael
> 
>