Use the Aggregate Design Pattern to Reduce Coupling

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
 +
Despite that fact that architects and developers knows that tight coupling leads to increased complexity we experience that large object models grow out of control with performance problems and lack of transactional integrity as practical results. There are many reasons for this to happen including: the real world is interconnected with few clear boundaries and our programming languages does not provide dynamic multi-object grouping mechanisms out of the box.
 +
 +
To illustrate the problem think of a simple order management system built from three objects: order, orderline and item. Assume now that the item price must be changed and what should happen with confirmed and delivered orders? Should the price also be changed for them? Most certainly not. The natural approach is that price and quantity are the main attributes of an orderLine object.
 +
 +
Dealing with this type of problems at large leads us to a set of design heuristics that was first published by Eric Evans in his book Domain-Driven Design under the title ''aggregates''. An aggregate is a set of objects that are defined to belong together and therefore should be handled as one unit when it comes to updates.
 +
Aggregates, one of Eric Evans core Domain-Driven Design patterns, is an important design strategy to master for those aiming for reduced coupling and enforced transaction boundaries in object models.
Aggregates, one of Eric Evans core Domain-Driven Design patterns, is an important design strategy to master for those aiming for reduced coupling and enforced transaction boundaries in object models.

Revision as of 15:11, 25 October 2008

Despite that fact that architects and developers knows that tight coupling leads to increased complexity we experience that large object models grow out of control with performance problems and lack of transactional integrity as practical results. There are many reasons for this to happen including: the real world is interconnected with few clear boundaries and our programming languages does not provide dynamic multi-object grouping mechanisms out of the box.

To illustrate the problem think of a simple order management system built from three objects: order, orderline and item. Assume now that the item price must be changed and what should happen with confirmed and delivered orders? Should the price also be changed for them? Most certainly not. The natural approach is that price and quantity are the main attributes of an orderLine object.

Dealing with this type of problems at large leads us to a set of design heuristics that was first published by Eric Evans in his book Domain-Driven Design under the title aggregates. An aggregate is a set of objects that are defined to belong together and therefore should be handled as one unit when it comes to updates.

Aggregates, one of Eric Evans core Domain-Driven Design patterns, is an important design strategy to master for those aiming for reduced coupling and enforced transaction boundaries in object models.


To be continued.

By Einar Landre


This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools