I am facing similar problem as Niclas, but currently it is on such
small scale that I've used queries to solve it. However, I have a
feeling that I will need to get rid of them because they will be used
so often that their slowness will begin to show.
The interesting question is, as Niclas anticipated, whether these
entity-local identities are currently easily implementable with
current identity mechanism in Qi4j. But I for one, would be also very
interested in having this kind of entity-local identity feature.
Quoting Niclas Hedhman <[email protected]>:
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.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
