StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Part of my answer seems to be captured in these posts:</p> <p><a href="https://stackoverflow.com/questions/2155845/domain-driven-design-parent-child-relation-pattern-specification-pattern">Domain Driven Design - Parent child relation pattern - Specification pattern</a></p> <p><a href="https://stackoverflow.com/questions/944045/best-practice-for-handling-nhibernate-parent-child-collections">Best practice for Handling NHibernate parent-child collections</a></p> <p><a href="https://stackoverflow.com/questions/566854/how-should-i-add-an-object-into-a-collection-maintained-by-aggregate-root">how should i add an object into a collection maintained by aggregate root</a></p> <p>To summarize:</p> <p>It is OK to create an entity outside its aggregate if it can manage its own consistency (you may still use a factory for it). So having a transient reference to Auto is OK and then a new Policy(Auto) is how to get it into the aggregate. This would mean building up "temporary" graphs to get the details spread out a bit (not all piled into one factory method or constructor). </p> <p>I'm seeing my alternatives as either:</p> <p>(a) Build a DTO or other anemic graph first and then pass it to a factory to get the aggregate built. </p> <p>Something like: </p> <pre><code>autoDto = new AutoDto(); autoDto.setVin(..); autoDto.setEtc... autoDto.setGaragedLocation(new Location(..)); autoDto.addDriver(...); Policy policy = PolicyFactory.getInstance().createPolicy(x, y, autoDto); auto1Dto... policy.addAuto(auto1Dto); </code></pre> <p>(b) Use builders (potentially compound): </p> <pre><code>builder = PolicyBuilder.newInstance(); builder = builder.setX(..).setY(..); builder = builder.addAuto(vin, new Driver()).setGaragedLocation(new Location()); Policy = builder.build(); // and how would update work if have to protect the creation of Auto instances? auto1 = AutoBuilder.newInstance(policy, vin, new Driver()).build(); policy.addAuto(auto1); </code></pre> <p>As this thing twists around and around a couple things seem clear. </p> <p>In the spirit of ubiquitous language, it makes sense to be able to say:</p> <p>policy.addAuto</p> <p>and</p> <p>policy.updateAuto</p> <p>The arguments to these and how the aggregate and the entity creation semantics are managed is not quite clear, but having to look at a factory to understand the domain seems a bit forced.</p> <p>Even if Policy is an aggregate and manages how things are put together beneath it, the rules about how an Auto looks seem to belong to Auto or its factory (with some exceptions for where Policy is involved). </p> <p>Since Policy is invalid without a minimally constructed set of children, those children need to be created prior or within its creation. </p> <p>And that last statement is the crux. It looks like for the most part these posts handle the creation of children as separate affairs and then glue them. The pure DDD approach would seem to argue that Policy has to create Autos but the details of that spin wildly out of control in non-trivial cases.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload