Hi Niclas, I've found about Qi4J about two months ago, and have already convinced my fellows to try it on a new project we are starting. We faced what I think is a similar problem to what you are describing, and on the brainstorming sessions we carried, what I heard most was 'if only there was support for Map within entities...'. Have you ever considered adding a subset of the Map interface (kind of MapAssociacion<?, ?>) to the possible associationss between entities? I understand this can be quite complex, but it has great potential for these situations, and would hide any UUID mangling strategy from the end users.
Just my 2 cents. Regards, Pablo Abad On 12/27/2010 10:35 AM, Niclas Hedhman wrote: > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
