Re: IDs in the domain

I do loosely couple between aggregates with soft links. I just don't use Id
classes to do it..

If you start lazy loading from Id classes I see a big mess coming. How many
user types will be needed for hibernate (yuck ESP with injection of
repository).

On Monday, May 13, 2013, Wim van Gool wrote:

> **
>
>
> @Greg: I agree that encapsulating identifiers with custom types might be a
> bit too puristic in the sense that you will hardly even change them - and
> not only that, but the encapsulation usually only takes place inside your
> domain. For example, if you encapsulate an integer, how are you going to
> send out this identifier to other systems? I'll guess you just send the
> integer. Even if you have made local refactoring easy by encapsulating this
> id, how will you then solve the problem of versioning the switch of your
> identifier type?
>
> Having said that, I think Michael is talking more about having explicit
> identifiers within your domain model at all - not the encapsulation
> mechanisme that is used by Vaugh per se. At this point I would personally
> argue that although identifiers are usually not part of the UL, they are a
> small yet effective means to loosely couple aggregates of your domain.
> Should you ever feel the need to 'iterate' from one aggregate to the next,
> you can do this through eventing or let you're application or domain
> service(s) take care of it - they will be able to access your repositories
> explicitly, whereas otherwise you are either forced to use a framework to
> support lazy loading, or to inject your repositories into your domain,
> which I am not particularly fond of. However, it's mostly a matter of
> personal choice I guess...
>
>
> On Mon, May 13, 2013 at 4:04 AM, Greg Young <[email protected]>wrote:
>
> **
>
>
> 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]
> http://www.schuerig.de/michael/
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>


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