Despite that fact that architects and developers knows that tight coupling leads to increased complexity we on an almost daily basis experience that large object models grow out of control with performance problems and lack of transactional integrity as the practical results. There are many good reasons for this to happen, including: The inherent complexity of the real world with few clear boundaries, insufficient programming language support for dynamic multi-object grouping and weak design practices.

+

Despite that fact that architects and developers know that tight coupling leads to increased complexity, we experience large object models growing out of control on an almost daily basis. In practice, this leads performance problems and lack of transactional integrity. There are many reasons why this happens: the inherent complexity of the real world, which has few clear boundaries; insufficient programming language support for dynamic multi-object grouping; and weak design practices.

-

To illustrate the problem think of a simple order management system built from three objects: order, orderline and item. The object model can be traversed as <code>order.orderLine.item</code>. Assume now that the item price must be updated and what should happen with confirmed and delivered orders? Should their price also be changed? In most cases certainly not. To secure that rule item price is copied into orderLine together with the quantity.

+

To illustrate the problem think of a simple order management system built from three object classes: <code>Order</code>, <code>OrderLine</code>, and <code>Item</code>. The object model can be traversed as <code>order.orderLine.item</code>. Assume now that the item price must be updated. What should happen with confirmed and delivered orders? Should their price also be changed? In most cases certainly not. To secure that rule, item price can be copied into <code>orderLine</code> together with the quantity.

-

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. The pattern also defines rules for how an object model is allowed to be connected where the following three are the most important:

+

Dealing with this type of problem 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 heading ''aggregates''. An aggregate is a set of objects defined to belong together and, therefore, should be handled as one unit when it comes to updates. The pattern also defines how an object model is allowed to be connected, with the following three rules considered to be the most important:

-

+

-

1)External objects are only allowed to hold reference to ''aggregate root''.

+

# External objects are only allowed to hold references to the ''aggregate root''.

-

2)Aggregate members are only allowed to be accessed through the ''root''.

+

# Aggregate members are only allowed to be accessed through the ''root''.

-

3)Member objects only exist in context of the ''root''.

+

# Member objects exist only in context of the ''root''.

-

+

-

Applying this rules on our simple order management system the following can be stated. Order is the ''root'' entity of the order aggregate. The aggregate has one member object ''orderLine''. Item is the ''root'' of another aggregate. Deleting an order implies that all its orderLines are deleted within the same transaction. Item is not affected by changes to orders. Orders are not affected by changes to items.

+

Applying these rules on our simple order management system the following can be stated: <code>Order</code> is the ''root'' entity of the order aggregate. The aggregate has one member object <code>orderLine</code>. <code>Item</code> is the ''root'' of another aggregate. Deleting an order implies that all of its <code>orderLines</code> are deleted within the same transaction. Items are not affected by changes to orders. Orders are not affected by changes to items.

Identifying aggregates can be a difficult design task, where refactoring and domain expertise is a must.

Identifying aggregates can be a difficult design task, where refactoring and domain expertise is a must.

Revision as of 19:57, 31 October 2008

Despite that fact that architects and developers know that tight coupling leads to increased complexity, we experience large object models growing out of control on an almost daily basis. In practice, this leads performance problems and lack of transactional integrity. There are many reasons why this happens: the inherent complexity of the real world, which has few clear boundaries; insufficient programming language support for dynamic multi-object grouping; and weak design practices.

To illustrate the problem think of a simple order management system built from three object classes: Order, OrderLine, and Item. The object model can be traversed as order.orderLine.item. Assume now that the item price must be updated. What should happen with confirmed and delivered orders? Should their price also be changed? In most cases certainly not. To secure that rule, item price can be copied into orderLine together with the quantity.

Dealing with this type of problem 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 heading aggregates. An aggregate is a set of objects defined to belong together and, therefore, should be handled as one unit when it comes to updates. The pattern also defines how an object model is allowed to be connected, with the following three rules considered to be the most important:

External objects are only allowed to hold references to the aggregate root.

Aggregate members are only allowed to be accessed through the root.

Member objects exist only in context of the root.

Applying these rules on our simple order management system the following can be stated: Order is the root entity of the order aggregate. The aggregate has one member object orderLine. Item is the root of another aggregate. Deleting an order implies that all of its orderLines are deleted within the same transaction. Items are not affected by changes to orders. Orders are not affected by changes to items.

Identifying aggregates can be a difficult design task, where refactoring and domain expertise is a must.