Re: IDs in the domain

Soft links do not require special Id classes. I have found guids to work
quite well (Uris work well too)

I run a risk that my domain would see a large change if I one day decided
to change all my dis but I don't tend to do this.


On Monday, May 13, 2013, Michael Schuerig wrote:

> On Sunday 12 May 2013, Dan Haywood wrote:
> > 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.
>
> Well, I've written my fair share of code that passes around IDs and I'm
> not particularly proud of it. My point, however, is slightly different.
> My understanding of DDD is limited and backed by even less practice.
> While reading IDDD, at first I just took the IDs for granted. As they
> appeared more and more often, I began to wonder. Currently, I think that
> they are not in accord with other DDD tenets as they unnecessarily
> introduce a purely solution-domain concept into the domain code.
>
> Now, the code modeling a domain can never just mirror it, of course
> there are always concepts that are artifacts of the technical solution.
> However, it's one thing to invite them into the living room of your
> domain logic and it's quite another thing to push them into the
> infrastructure basement.
>
> After reading on a bit in IDDD, as far as I can tell, there the
> principal reason for IDs ("identity references", p.359) is to insulate
> aggregates from one another. Among other things, aggregates define
> transaction boundaries. In order to avoid inadvertently straying into
> another aggregate by innocently following an _object_ reference, let's
> replace those with _identity_ references. Then, instead of traversing a
> reference (myAggregate.externalEntity()) you have to pair off an ID with
> a repository
> (externalRepository.entityOfId(myAggregate.externalEntityId())). IOW,
> "If I can't keep you from doing something you shouldn't, I'll make it
> painful at least."
>
> In theory that may sound right. In practice I either need the external
> entity to implement some functionality or I don't. And if I do need it,
> the additional pain doesn't help.
>
>
> > > 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).
>
> I can't follow the argument, I think. I have no objection to entities
> having IDs in the sense of surrogate keys. Also, I see the point in
> having policies on when and how these IDs are created and set. What I'm
> concerned about is treating IDs as separate things from the entities
> whose identity they represent.
>
>
> I hope I'm not using too much force beating a dead mosquito. It's a
> small issue, but I stubbed my toe on it.
>
> Michael
>
> --
> Michael Schuerig
> mailto:[email protected] <javascript:;>
> http://www.schuerig.de/michael/
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

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