Microsoft .NET Architecting Applications for the Enterprise, Second Edition (2014)

There are a few interesting things to say about the Items and Total properties. Let’s start with bringing up some issues related to having collections in an aggregate. We describe the issues and provide some suggestions. The definitive answer, though, will come in the next chapter and from the use of a different DDD supporting architecture—CQRS instead of Domain Model.

The Items property is defined as a collection. This means that any code that receives an Order instance can enumerate the content of the collection but can’t add or remove items. Unfortunately, there’s no easy way to prevent that client code from accessing and updating content within the collection. Even worse, this aspect remains unaltered even if you further restrict the collection to a basic IEnumerable<T>. The following code is always allowed and, in addition, you can always use LINQ to select a particular order within the collection:

someOrder.Items.First().Quantity++;

In our scenario, an order is read-only. It gets created out of the checkout process; it can’t be modified, but it can be viewed. So you want the Items collection to be consumed as read-only content. How can you prevent changes on the objects within the collection? Unfortunately, even the following won’t work:

public class Order
{
private Collection<OrderItem> _items = new Collection<OrderItem>();
public ICollection<OrderItem> Items
{
get { return _items.AsReadOnly(); }
}
}

The Items collection is read-only, but you can still retrieve individual elements and change them programmatically.

The definitive solution to this problem comes with the separation between queries and commands and with the provision of different models for reading and writing operations. We’ll cover this in the next two chapters.

The Total property indicates the total value of the order. How should you deal with that? The property is there to please code that consumes the content of the order. In theory, the total of an order can be calculated on demand, iterating on the order items graph with an ad hoc method:

public Money GetTotal()
{
var amount = Items.Sum(item => item.GetTotal().Value);
return new Money(Currency.Default, amount);
}

This solution, though, has a significant drawback. It forces the Order instance to have in memory the entire graph of items. There might be scenarios in which you just want to know the about the total of the order, without all the details. A method like GetTotal will force the deserialization of the entire graph and create much more traffic to and from the database.

By having a simple property on the Order, you can decide intelligently whether or not to deserialize the entire graph. The Total property can be set by the order repository when it returns an instance (which could be a simple SUM operation at the SQL level), or it can be the result of some redundancy in the relational schema of the database. Whenever the order is persisted, the current total is calculated and saved for further queries.

The FidelityCard aggregate

The FidelityCard aggregate is an extremely simple class that summarizes through the accrual of points the activity of a customer within the site.

public class FidelityCard
{
public static FidelityCard CreateNewCard(string number, Customer customer)
{
var card = new FidelityCard {Number = number, Owner = customer};
return card;
}
protected FidelityCard()
{
Number = “”;
Owner = UnknownCustomer.Instance;
Points = 0;
}

public string Number { get; private set; }
public Customer Owner { get; private set; }
public int Points { get; private set; }

public int AddPoints(int points)
{
Points += points;
return Points;
}
}

Each order a customer places increases the total points on the card, and those points are then used to determine a reward status the customer can use to get additional discounts. All the logic of discounts and levels is inspired by the business domain and can be as complex and varying as the real world requires.

The content of a FidelityCard object is used by domain services to calculate reward levels and discounts.

Special cases

In the context of a domain model, one of the most commonly used accessory design patterns is the Special Case pattern, which is defined here: http://martinfowler.com/eaaCatalog/specialCase.html. The pattern addresses a simple question: when some code needs to return, say, a Customerobject but no suitable object is found, what is the best practice? Should you return NULL? Should you return odd values? Should you make an otherwise clean API overly complex and make it distinguish whether or not a result exists? Have a look at this code. It belongs to theOrderRepository class of I-Buy-Stuff and retrieves an order by ID while restricting the search to a particular customer ID:

public Order FindByCustomerAndId(int id, string customerId)
{
using (var db = new DomainModelFacade())
{
try
{
var order = (from o in db.Orders
where o.OrderId == id &&
o.Buyer.CustomerId == customerId
select o).First();

return order;
}
catch (InvalidOperationException)
{
return new NotFoundOrder();
}
}
}

The First method throws if the order is not found. In this case, the code returns a newly created instance of the class NotFoundOrder:

public class NotFoundOrder : Order
{
public static NotFoundOrder Instance = new NotFoundOrder();
public NotFoundOrder() : base(0, UnknownCustomer.Instance)
{
}
}

NotFoundOrder is just a derived class that sets all properties to their default values. Any code that expects an Order can deal with NotFoundOrder as well; and type checking helps you figure out if something went wrong:

if(order is NotFoundOrder)
{
...
}

This is the gist of the Special Case pattern. On top of this basic implementation, you can add as many additional features as you want, including a singleton instance.

Persisting the model

A domain model exists to be persisted, and typically an O/RM will do the job. All that an O/RM does as far as persistence is concerned is map properties to columns of a database table and manage reads and writes. This is only a 10,000-foot, bird’s-eye view, though.

What an O/RM does for you

Generally speaking, an O/RM has responsibilities that can be summarized in four points:

CRUD

Query engine

Transactional engine

Concurrency

The query and transactional engines refer to two specific design patterns: the Query Object pattern (which you can see at http://martinfowler.com/eaaCatalog/queryObject.html), and the Unit of Work pattern (which you can see at http://martinfowler.com/eaaCatalog/unitOfWork.html).

Today, on the .NET platform nearly all O/RMs offer an idiomatic implementation of the Query Object pattern based on the LINQ syntax. The Unit of Work is offered through the capabilities of the O/RM root object. In Entity Framework, this object is ObjectContext in its various flavors, such as DbContext.

An O/RM is an excellent productivity tool. It doesn’t really do magical things, but it saves you a lot of cumbersome and error-prone coding. All that it requires is instructions on how to map properties of objects in the domain model to columns of relational database tables.

When it comes to this, you realize that the database is really important even if you do domain-driven design and build a model that is persistence ignorant and stay as agnostic as possible with regard to databases. In a nutshell, the database and the O/RM are two constraints that typically force you to make concessions and introduce in the model features that only serve the need of persistence.

Making concessions to persistence

The most common concession that you, as a Domain Model architect, have to make to an O/RM is the availability of default constructors on all persistent classes.

protected Customer()
{
// Place here any initialization code you may need
...
}

The constructor is required for the O/RM to materialize an entity from the database. In other words, it still needs low-level tools to create an instance of that class. Factory methods are an abstraction that serves the purpose of the ubiquitous language. The constructor, on the other hand, is the only known way that compilers in C# (and other object-oriented languages) allow you to create fresh instances of a class.

Nicely enough, though, you can use O/RM tools to hide the default parameterless constructor from public view. When materializing an entity from databases, an O/RM usually returns the instance of a dynamically created class that inherits from the real entity. In this way, the dynamically generated code gains access to the protected constructor.

Beyond this point, other changes you might be forced to do to make the model persistent depend on the capabilities and quirks of the O/RM of choice. For example, up until version 5, Entity Framework was unable to deal with enum types. In version 6.1, it is still unable to handle, at least in a default way, arrays of primitive types.