Thursday, October 14, 2010

Domain Driven Design (DDD) implementation using C# and LINQ

The part of the software that specifically solves problems from the domain model usually constitutes only a small portion of the entire software system, although its importance is disproportionate to its size. To apply our best thinking, we need to be able to look at the elements of the model and see them as a system.We must not be forced to pick them out of a much larger mix of objects, like trying to identify constellations in the night sky.We need to decouple the domain objects from other functions of the system, so we can avoid confusing domain concepts with concepts related only to software technology or losing sight of the domain altogether in the mass of the system. Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans 
(Addison-Wesley, 2004)

Aggregates and Simplification
The DDD way to break down this complexity is to arrange domain entities into groups
called aggregates.
Each aggregate has a root entity that defines the identity of the whole aggregate, and acts
as the “boss” of the aggregate for the purposes of validation and persistence. The aggregate is
a single unit when it comes to data changes, so choose aggregates that relate logically to real
business processes—that is, the sets of objects that tend to change as a group (thereby embedding
further insight into your domain model).
Objects outside a particular aggregate may only hold persistent references to the root
entity, not to any other object inside that aggregate (in fact, ID values for non-root entities
don’t even have to be unique outside the scope of their aggregate). This rule reinforces
aggregates as atomic units, and ensures that changes inside an aggregate don’t cause data
corruption elsewhere.

In our example we have 3 aggregates (Customer,Store and Item)

code file password (

No comments:

Post a Comment


Search This Blog