Posts Tagged ‘DDD’

DDD and Aggregates

Friday, September 26th, 2008

I started reading Eric Evans’ book Domain Driven Design.  (Seemed like one of those foundation books you have to have read if you want to be a certain type of developer)  I decided to give it a go after I got about halfway through the “Domain Driven Design Quickly” pdf – it seemed interesting enough that I wanted to have a go at the real thing.

Anyway, one thing it talks about is Aggregates… basically, a tree of dependent objects that don’t mean anything alone-like line items to an order, as opposed to a customer that is an entity that has meaning by itself.  I guess I haven’t explored things enough yet, but I’m thinking abouton something I’m looking at-I’ve got something like an order, and something like a line item.  There should be no separate repository for the line item.  However, in practice you may need to deal with the line item by itself, for instance the “edit the line item” screen on a website.  In a desktop app, you’d pull out the line item w/ roder, keep that around, and then save when the editing’s done.  However with this web scenatio, you come back from the editing screen and have… some IDs.  Sure, you may have selected the line item from the order… but as the web is stateless, you don’t have your order and order item all ready to update, you’ve got to rebuild that and apply the changes before a saving.  So, you’d pull out that line item from the repository *via the ID*. Or if you prefer, pull out the order via its ID, then iterate through its line items and pick out the relevant line item from the line item collection by ID.. also messy-you preserve the aggregate idea since there’s now no repository for  line items, but you’ve got iteration, and worse, a domain-level usage of picking by ID, which feels like bleed-through.  But you really need the order and the order item, so you can make your changes and then save.  Uh, I guess you can put them in your session, but that just seems even worse than either of the above options due to unreliability.  But maybe that’s me being pessemistic.  anyway, is there a clean way do deal with this?  Or at least a generally agreed-upon lesser evil?