Design patterns used in DDDSample.Net


Aggregate is subset of model of particular bounded context. Aggregate contains one or many entities and has exactly one 'root' -- an object which is a facade of whole aggregate. No external objects can hold reference to any internal aggregate objects other than its root. Identities of internal aggregate objects are scoped within their aggregate. Only the aggregate roots can be directly, through Repositories, retrieved from the persistent storage backing the model. All the other objects must be reachable by traversing model relations.

Aggregates help to structure the domain model. They promote encapsulation of logic. Aggregates can be seen either as a property of a model itself (DDD book) or as a means of structuring logic in particular use cases.

Aggregates are also significant from technical perspective: their provide boundaries for transactional behaviour and thus allow scaling the model.

See aggregate discussion for classic version of DDDSample.Net


Great description of event-related concepts in the domain model can be found on Greg Young's blog. There are three different usages of this concept in DDDSample.Net.

Modeling changes as events

First one introduces a new kind of element into the model. The Event has some characteristics of an Entity (own thread of identity) and some of a Value Object (should be immutable after creation). Events of this kind are used to make changes to the model explicit.

In classic version of DDDSample.Net, the HandlingEvent object is an example of Entity pattern.

Publishing changes using events

Second incarnation of event concept is used to publish the changes rather then model them. It has been popularized by Udi Dahan and his blog post series. Is is a behavioural pattern which solves the problem of getting data out of domain model without breaking its encapsulation. The solution is to enable domain objects to publish the data in form of events which as delivered to all registered listeners / handlers. Domain Events pattern is not means to solve performance issues as it assumes synchronous event handling on the same thread.

Domain Events are widely used in most DDDSample.Net versions. For example, in classic version they are used to pass information between Cargo and Handling aggregates. The infrastructure that enables usage of this pattern is fairly small. Is is based on solution published by Udi. You can see example of code raising events here and a corresponding event handler here.

Third incarnation is the Event Sourcing pattern which is described later.


An Entity represents a domain concept with its own thread of identity. This unique identity, rather than attribute values, define the Entity instance.

Value Object

A Value Object represents a domain concept defined entirely by its attributes. It has no unique identity and two Value Object instances with same attributes can be considered as same.


A Repository is a supporting element in the domain model. It does not represent any real-world concept. A repository is bound to an aggregate and is used to manage the middle phase of lifecycle of aggregate root objects -- persist and retrieve from persistent form.

Domain Service

A Domain Service represents a stateless real-world concept. If a behavior cannot be bound to any Entities or Value Objects, it can be represented as a stand-alone Domain Service.

There is one Domain Service in DDDSample.Net -- the RoutingService. It is represented differently in various versions. In the most direct port of Java DDDSample, vanilla version, RoutingService is represented by an interface placed in the domain model. Its implementation, however, is not considered a part of the model. Rather than, it is an anti-corruption layer which translates between domain model's ubiquitous language and external graph traversal service API.
In the Layered Model version RoutingService is a part of Decision Support layer. Both interface and implementation in placed in the domain model assembly. This is because in this version implementation is not only responsible for translating to other API but also for applying various policies to the route selection process (such as customer-specified best-route policy).

Event Sourcing

Architectural patterns used in DDDSample.Net

Layered Architecture


Last edited Apr 18, 2010 at 9:38 AM by SzymonPobiega, version 2


No comments yet.