So I’ve got a rather simple, mostly crud application I want to use DDD with, to learn/practice it. I wonder about aggregate design regarding a fuel tank entity. Each tank stores fill level readings (date, fill level), usually one each year, and gets several deliveries of fuel per year (date, amount, cost).
Looking at invariants, the two collections are independent from each other, and I can only see one business rule for the fill level readings: there must only be one reading for any given date.
Regarding usage patterns, the two collections are edited independently as well, because a delivery rarely happens on the same day that readings are taken. When reading a tank to display it, however, the most recent values of both collections are also needed.
What does that mean for aggregate design? I roughly see three options:
- One big tank aggregate containing both collections. I can maintain the invariant, but always need to load both collections even when only editing one. (Then again, they’re small enough that their size shouldn’t be an issue in my example, after 20 years a tank would roughly have 60 deliveries.)
- One tank aggregate, one aggregate for the tank level collection, one for the deliveries collection. The invariant can be maintained within the collection aggregate, and i only need to load the collection that actually gets modified.
- One tank aggregate, but each tank level and delivery would be their won aggregate, so no collection aggregates. The invariant cannot be maintained in the model anymore, but it’s a simple unique constraint so i could put that into the db layer. I only need to load and save the single values i edit, no more collections.
Given this simple albeit maybe a little vague example, do any of you with experience in DDD have a preference for an aggregate design or even a different design idea altogether?
4
I wonder about aggregate design regarding a fuel tank entity.
OK, so one of the things that you have to have clear in your head, is where the “book of record” lies. If you are dealing with a collection of readings from a physical fuel tank, then the book of record is outside of your model (you can’t add fuel to the tank by changing numbers in your digital representation).
Truth is what’s actually in the tank; the readings from the sensors give you some approximation of that truth (which may or may not be reliable, depending on the quality of the sensors), your inputs are digital representations of those readings (hopefully without too many transcription errors), and your database is “just” a collection of cached copies of those digital representations.
In this sort of situation, your “aggregates” turn out not to be very interesting, because there’s not much for them to do (other than perhaps check if some message has already been written down).
Aggregates are a lot more interesting when you have processes. For instance, we might have a process that is responsible for deciding when to order more fuel from the vendor. So when new information from one of the fuel tank sensors arrives, we might load stored information about the deciding, integrate the new sensor data, and update our decisions about when to schedule an order.
In very rough terms, the aggregate is interesting because it is writing down things other than just the facts it was told and what it writes down next depends (in part) on what it has written down before — i.e. its own internal state, over which it is the sole authority.
CRUD tends to suggest that you are designing a database, so don’t be in a hurry to implement a bunch of patterns that are more appropriate to a service.
For more on the book of record problem, search for discussions of modeling warehouse systems.
1