I've been working with modeling an entity that could be an aggregate of
a set of other types. I was thinking of doing this one of two ways,
either as a set assocation or a Collection property. So, something like
public interface ItemStyle extends Nameable {
ImmutableProperty<Collection<ItemStyle.Iteration>> iterations();
Iteration newIteration(@NonEmptyString String name);
interface Iteration extends Nameable {}
}
In the above, the ItemStyle would be responsible for creating new
Iterations, which is something I kinda want as there are rules like the
name of an iteration must be unique within a given style. So, in the
DDD sense the ItemStyle is an aggregate and the style is composed of
Iterations. The alternative is to use a SetAssocation
public interface ItemStyle extends Nameable {
@NotEmpty SetAssociation<ItemStyle.Iteration> iterations();
interface Iteration extends Nameable {}
}
This means the Iteration would have to be an Entity instead of a
Composite and be managed externally to the ItemStyle. I prefer the
first alternative but that would require something that uses an item
style to have at least two fields to track what iteration of the style
it is a part of, the style itself and the name of the iteration (to
avoid breaking the DDD rules of aggregates that nothing outside the
aggregate should hold a direct reference to an entity that is part of
another aggregate).
Which design to go with isn't really what this email is about. What I'm
curious about is how to work with these different situations.
In the first case, the iterations property should be Immutable because
only the ItemStyle itself should manage the collection. But that only
limits calling the style.iterations().set() method, but users are free
to modify the collection by calling style.iterations().get() and using
the regular collection modifiers. Could it, and should it, also make
sure that the collection returned by get() is unmodifiable?
Another question I have about that situation is the creation of entities
with these immutable Collection properties. If I just do
unitOfWork.newEntity(ItemStyle.class) that leaves the iterations
property as null. Instead, I can use the
unitOfWork.newEntityBuilder(ItemStyle.class) and then use the
stateOfComposite() to set the iterations property before creating a new
instance. Naturally, this would be a bit of a pain everywhere I want to
create an ItemStyle instance, so I was thinking of just creating an
ItemStyleFactory as a service and using that to abstract the creation
process. Does that sound like the right way to handle this or is there
another way to handle this?
I guess I don't really have many questions about the second case, I do
kinda wonder if I can limit the ability of external users to modify that
association directly and have it all handled via methods in the
ItemStyle interface.
And if you care to chime in on having just the 1 aggregate or 2, feel
free. I think I'm leaning towards just one aggregate and using helper
methods/objects to manage the need to fetching of the right iteration
when it's needed.
Thanks,
Rich
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
