Re: IDs in the domain

On Sunday, 12 May 2013, Michael Schuerig wrote:

> >
> > > Is the approach in IDDD representative?
> >
> > It's a particular design.  It works.  Like any design, it has
> > trade-offs. It's not the only way.
>
> Well, that's the question, really. Are explicit IDs in the domain
> acceptable by the demanding standards, DDD otherwise imposes?


I guess you must make your own mind up whether you accept them or not....


> I'd say
> that if IDs do not appear in the UL, they don't have a place domain
> code.


... it sounds like you don't accept them.  I definitely lean towards the
same point of view.  Most others on this mailing list would say it is
acceptable, though.



> Also, as they can be mapped to proper entities at the boundary,
> there is no pressing need for such IDs inside the Bounded Context.
>
>
It depends, somewhat, on the implementation of the infrastructure layer.
 If using a NoSQL persistence with heavy emphasis on aggregates and
eventual consistency, then, yes, they are pretty much required, it would
seem.  If using an ORM with an RDBMS and transaction isolation levels, then
no, there's no real need for them (at least, not within a BC).




> Before anyone objects to the presumed inefficiency: For the purposes of
> a specific BC, an entity may consist of nothing but its identity or it
> may load its attributes lazily.
>

Indeed.


>
> I'm not a long-time member of the DDD community and so I don't know what
> the actual practices are. Maybe nobody writes code like it is shown in
> Vernon's IDDD. But then I'd be surprised that apparently reviewers
> didn't object to it.
>

I was one of the reviewers of Vaughn's book, at least for the early
chapters.  I got rather too busy to continue, and it was also increasingly
clear that the implementation approach that Vaughn describes wasn't one
that I would have much to say about (it not being the way that I build DDD
systems).  But I won't say you can't build things this way, I imagine that
Vaughn has done so several times, and it does seem to be the most commonly
discussed approach on this mailing list.

As I say, though, it's not the way that I implement DDD systems.

Dan



>
> Michael
>
> --
> Michael Schuerig
> mailto:[email protected]
> http://www.schuerig.de/michael/
>
>
>