Re: IDs in the domain

One argument often used for the Id classes is that you can change the type
of Id easily (int to guid etc).

I don't buy it. I rarely if ever use Id classes (one case would be for
multi keys)

On Sunday, May 12, 2013, Michael wrote:

> **
>
>
> 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
>
>  
>


-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.