Note that there are some explanatory texts on larger screens.

plurals
  1. POAccessing Subclassed Aggregate Members
    text
    copied!<p>I understand that we should not change children of an aggregate-root directly, but instead they should be performed via methods on the aggregate-root. E.g. <code>order.SetOrderLineQty(product, qty);</code></p> <p>But what if the children of the aggregate-root are something abstract? Imagine you have Car aggregate root, which contains a list of IWheel as part of the aggregate. How would you add/change the properties of the wheel via its aggregate-root (who knows nothing about what the concrete type of wheel they might be)?</p> <p>A more real world example is this: A doctor can create a MedicalRerport (aggregate-root), which contains a list of IMedicalNote (as part of MedicalReport aggregate). IMedicalNote is a base-class/interface, which is subclassed into a few concrete subclasses, e.g. BloodCheckNote, TemperatureNote, MineralConcentrationNote, etc etc.</p> <p>Each subclass has different properties, and they're all editable. A MedicalReport aggregate may contain one or more of any of these notes. (Each note subclass has a specific user-control for the user to enter/update the details, shown as panels/tabs under the big MedicalReport screen)</p> <p>My question is, how can I add/edit the properties of these notes strictly via its aggregate-root (MedicalReport)? Since I am not allowed to change these notes properties directly, one ugly option is by exposing all possible note properties on the aggregate root (MedicalReport), i.e.:</p> <pre><code>report.SetWhiteBloodCellCount(cellCount); report.SetBloodCheckComment(comment); report.SetTemperature(bodyPart, temperature); report.AddMineral(mineral, concentration); </code></pre> <p>Each of these methods will update (or create new) note items in its internal children collection. There are 2 obvious problems with this:</p> <ol> <li>We have to define upfront all available properties of all possible IMedicalNote subclasses on the aggregate-root. That's not acceptable as the number of subclasses is guaranteed to grow, depends on the type of medical data we want to capture, which is the whole point of the inheritance in the first-place.</li> <li>There can be multiple instances of the same note-type within the list. This API will fail, since we can't just say <code>report.SetBloodCheckComment(comment)</code> and expect it will update a BloodCheckNote item in the list, because we allow more than one BloodCheckNote items in the list.</li> </ol> <p>I still want to maintain all interactions to these notes via its aggregate-root, since it has to control whether the whole MedicalReport aggregate is valid to be saved, whether the aggregate is not modifiable, coarse-grained optimistic-concurrency check, etc. But how can I do that?</p>
 

Querying!

 
Guidance

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