Editor's Note - Architecture and Aggregates

By Howard Dierking | June 2009

As you can see from the article lineup, we're focusing this month on issues related to software architecture. And along those lines, I want to take advantage of this editor's note to talk about something that I've spent some time thinking about recently—aggregates.

Now, those of you who I have had the pleasure of getting to meet (or those of you to whom I am related) can attest to at least two things about me. First, I'm always excited to talk about software development—architecture in particular. Secondly, in such conversations, I tend to talk louder and faster as my excitement grows (this is amplified by adding someone like my good friend Glenn Block to the mix). Aggregates is one of those architectural topics that I get really excited about, so make sure to turn down your speakers.

An aggregate is a term used heavily by practitioners of domain driven design (DDD) and is defined as "a cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE'S boundaries."

Now let me say that I am not only a believer in this way of decomposing and thinking about a model, but I further believe that the failure to create strong aggregate boundaries is one of the major drivers behind spaghetti-like application designs that are hopelessly coupled to a relational database schema, and too intertwined to easily evolve to support message-based paradigms, such as those used in cloud computing architectures.

However, in some cases, I think we may be going about the process of defining aggregate boundaries in a sub-optimal way. I think at the root of the problem is that regardless of whether you design a database first or an object model first, both representations yield a structure of fine-grained logical entities—and this way of thinking about the abstractions can cause us to overlook opportunities to simplify.

To put this into an example, I've been working on developing a Microsoft Word add-in to tie article metadata to the manuscript. The metadata is managed in SharePoint—which, in database terms, feels more like the star topology of a Kimball-style data warehouse.

I started designing my application by creating a domain model. The initial scenario that I wanted to support was browsing the list of articles and selecting the article that the manuscript should be associated with. Because I wanted to not overwhelm my users with a giant list of articles, I added navigation to the scenario using a natural hierarchy whereby Magazine contains Issues which contain Articles. Sound familiar?

So what's the problem? This model looks similar to models we've all seen countless times over. However, it is also for this type of model where people run into trouble defining aggregate boundaries. Why? Because it is based on structure rather than behavior. To recap my scenario, I want to enable my users to navigate a set of articles using a natural hierarchy. By that logic, my hierarchy is simply a projection over a set of articles—and this changes my model such that I have a clearly defined, single article aggregate, as shown above.

Now, this is not to say that you should never have traditional hierarchies in your object models. Instead, I am trying to say that rather than defining aggregates by attempting to draw a line around a group of classes in a model, first define the course-grained aggregates based on behavior—then let your classes emerge inside the aggregate definition. You will avoid the analysis paralysis of trying to get the aggregate definitions "right" and you'll be starting out on the right foot, building your system based on behavior over structure.

Visit us at msdn.microsoft.com/magazine. Questions, comments, or suggestions for MSDN Magazine? Send them to the editor: mmeditor@microsoft.com.

Thanks to the following Microsoft technical experts for their help with this issue: Jean-Paul Boodhoo, Pablo Castro, Ben Constable, Jeff Derstadt, Chuck Esterbrook, Eric Fabricant, Steve Freeman, Ashok Kamath, Bertrand LeRoy, Nat Pryce, Ashish Shetty, Don Smith, Chris Tavares, Kevin Hoffman, Dave Fugate, Harry Pierson, Curt Hagenlocher, Lynn Langit, Varsha Mahadevan, Stephen Toub, Mark Lawrence, and Henri Socha.

Editor's Note - Architecture and Aggregates

Additional resources