Re: IDs in the domain

We are discussing a slowly changing dimension problem here. Something like
a person's name may never change, or may change once in a long while. But
given that large numbers of things are a problem in our designs, the id
represents the one and only immutable on many objects.

So the question is, if that immutable becomes the reference, either as guid
or int or some other thing, then the API should support a notification of
change mechanism, either as a query, or as a callback, or both. We dont do
it normally because it isnt a 'big problem' most of the time. The
historical nature of data is hard to represent in most databases because
time is an ignored dimension unless you specifically code for it, but it is
very DDD to consider time. I consider IDs to be like the handle on the milk
jug. You dont drink it, but you definitely want it when you buy a big jug
of milk. So someone inevitably asks when is it big enough? Now is a good
time to call it. Later is always too late.

Then someone says 'ok but dont actually use it'. Ok why? it IS an ID. There
is seldom any good reason to change one, and if it is at risk then insist
on a guid and stop arguing. If THAT isnt good enough you have a domain
problem, not an ID problem.


On Mon, May 13, 2013 at 5:29 AM, Greg Young <[email protected]> wrote:

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