On Mon, Dec 27, 2010 at 11:38 AM, Rickard Öberg <[email protected]> wrote: > On 2010-12-25 09.51, Niclas Hedhman wrote: >> >> I have a series of upcoming demands to support entity-local >> identities, and in some cases the number of entities are numerous, in >> the 1000s of the aggregating entity. Worse is that I don't really >> control the implementation, downstream developers will make the domain >> models, and I want to make their experience the best. >> One option is to do Identity mangling, having semantics built into the >> identity string itself, and build some kind of support library that >> deals with this. But that feels like a hack, and I would like to >> tackle this at the root itself; Support for entity-local identities. > > Can you first of all describe why simply UUID's, even for "owned" entities, > doesn't work? That's how I do it, and it's very easy to get going.
Uhhh... Isn't the 'burden of guilt' wrongly put here? I have a recurring pattern where aggregates have well understood 'parts', The domain model is indeed expressed like this, and requesting domain modelers to do "Identity mangling" sounds a bit unreasonable, as a) they shouldn't be bothered, b) sometimes the aggregate Identity is under the control of users/systems, so not only does the modeler need to make proper separation of aggregate:part, but proof the aggregate's identity from the used separator (not trivial for ordinary people). The kind of local identities varies; * Named views (in the range of dozens to hundreds). The requesting user has a particular view of each piece of data. Views are added removed over time, but shared across entities. * End-Of-Day capture, historic record of snapshot at a particular point in time. Self explanatory; capture a snapshot of some part of the aggregate into an Immutable record. Example; FX Rates. * Constituent references, from dozens to thousands. Many types of entities have break down of the 'full' information to its constituents creating that entity. An IndexDividend entity (subtype of Dividend) contains the contributing dividend from each of its constituents (well, much more complex than that, but for sake of making it understandable...). The alternative would be something like; Property<String,String> localIdToUuidsMap(); instead of Associations, in which case a lot of semantics are lost. OR slow queries... OR YOUR solution, which must be easy for ordinary mortals to use and not get messed up. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
