public interface IMessageFomatter
{
    string Format(string message);
}

Instead of doing all the work in the implementation of this interface, the message formatter will aggregate several distinct rules.  An inversion of control tool is configured to compose these rules and provide them to the formatter.

public class MessageFomatter : IMessageFomatter
{
    private readonly IFormatRule[] _rules;

    public MessageFomatter(IFormatRule[] rules)
    {
        _rules = rules;
    }

    public string Format(string message)
    {
        foreach (var action in _rules)
        {
            message = action.ApplyRule(message);
        }
        return message;
    }
}

In this way each rule can be small, testable, and have only one job.  I can add functionality to the formatting process without changing the formatter or any existing rule. 

public interface IFormatRule
{
    string ApplyRule(string text);
}

public class DisclaimerRule : IFormatRule
{
    public string ApplyRule(string text)
    {
        return text + "\nDisclaimer: This message will self-destruct";
    }
}

public class UppercaseRule : IFormatRule
{
    public string ApplyRule(string text)
    {
        return text.ToUpper();
    }
}

This technique is extremely powerful and we use it all over the place in our projects.

Recently we were building a search screen.  It has several text input boxes and select lists and radio button groups, you know, the standard enterprisey UI mess.  Anyway, that’s what it was and it’s a common feature in the apps I work on. I’ve seen the scenario over and over. But armed with the above technique and LINQ to NHibernate, we were able to craft a much more elegant solution than we had previously created.

First we have a type that represents the search query.  It could be implemented by the class that represents the user interface form or be built by the user interface layer.  It’s sent to a service that will perform the query.

public interface IProductSearchQuery
{
    decimal? Price { get; set; }
    int? PriceRange { get; set; }
    string Name { get; set; }
    ProductCategory Category { get; set; }
    // ...
}

public interface IProductRepository
{
    Product[] Search(IProductSearchQuery query);
    // ...
}

What we don’t want is a huge method that checks to see if a search criteria exists and then conditionally appends predicates to a database query.  That’s the old school way, and it’s a beast to test and to change.  Adding a user interface element, like a new text input field, would require us to change that big method by introducing repetitive and dangerous new code.

What we do want are small, isolated specifications that we can aggregate like the message formatter.

public interface IProductSearchFilter
{
    bool ShouldApply(IProductSearchQuery query);
    IQueryable<Product> Filter(IQueryable<Product> candidates, IProductSearchQuery query);
}

An example filter:

public class PriceRangeFilter : IProductSearchFilter
{
    public bool ShouldApply(IProductSearchQuery query)
    {
        return query.Price.HasValue && query.PriceRange.HasValue;
    }

    public IQueryable<Product> Filter(IQueryable<Product> candidates, IProductSearchQuery query)
    {
        return from product in candidates
               where product.Price <= (query.Price + query.PriceRange)
               && product.Price >= (query.Price - query.PriceRange)
               select product;
    }
}

You can test drive this thing.  It’s small and distinct.  And using LINQ to NHibernate you can combine several of them in a way that produces one select.

public class ProductRepository : IProductRepository
{
    private readonly ISession _session;
    private readonly IProductSearchFilter[] _filters;

    public ProductRepository(ISession session, IProductSearchFilter[] filters)
    {
        _session = session;
        _filters = filters;
    }

    public Product[] Search(IProductSearchQuery query)
    {
        var products = _session.Linq<Product>();
        return _filters
            .Where(x => x.ShouldApply(query))
            .Aggregate(products, (candidates, filter) =>
                filter.Filter(candidates, query)).ToArray();
    }

    // ...
}

One tricky spot for a lot of people is that Aggregate call.  It does the exact same thing as the foreach in the message formatter: passes the seed (products, in this case) through the filters aggregating the result.  The lambda parameter variable candidates is the result of the previous filter (or the seed for the first filter).  In other ecosystems besides .NET, Aggregate is called reduce.  You can see why – each filter reduces the candidates according to its specification.

When you think about it, an entire architecture could be a reduce. That would be really interesting.

If it’s not clear how to model a particular element in your model, try asking “which one?” If the question makes sense within your own scenario then you’re probably dealing with entities. If the question “which one” is meaningless in the context of your domain then you’re probably better off modeling the subject of the question as a value object.

I suggest that if you’re maintaining a collection, you implicitly care which one.

It is a mistake to attempt to maintain a collection of Value Objects.

Let’s take the near-canonical Address, a perfectly valid Value Object as described on page 98 of the Big Blue Bible:

public class Address : ValueObject<Address>
{
    public virtual string StreetAddress1 { get; set; }
    public virtual string StreetAddress2 { get; set; }
    public virtual string City { get; set; }
    public virtual State State { get; set; }
    public virtual string ZipCode { get; set; }
    public virtual Country Country { get; set; }
}

And a perfectly valid usage of this Address Value Object is as a component of an Entity:

public class Customer : Entity
{
    public Address WorkAddress { get; set; }
    public Address HomeAddress { get; set; }
    // ...
}

This, on the other hand, is incorrect:

public class Customer : Entity{
    private readonly ISet<Address> _addresses = new HashedSet<Address>();

    public Address[] GetAddresses()
    {
        return _addresses.ToArray();
    }
}

Again, distinguishing addresses by maintaining a collection of them implies identity. If you tried to edit one of the addresses respecting some immutable Value Object oriented thinking, you would clear the collection, find (somehow) the one you intended to edit, replace it along with all the others.  This is not possible.  When you only care about the values of an object, rather than a key, you cannot find the original one you intend to edit from an instance of an edited object.  If you care about a key you have an Entity.

The original and the edited will never match. You might try to give the Value Object a database key so that it is easy to find.  But if you do that, why again are you clearing all the rest and re-adding them?  That doesn’t make sense – just edit it.

There’s another problem.  In the “wallet” example you have paper money in your wallet, several pieces of paper.  Your wallet is the Entity and the money is a Value Object.  If you were to take some money out of your wallet, you would subtract from the Value Object, not remove an instance of the Value Object from a collection.  You don’t care if you have five ones or one five, you just care that you have five.  Value Objects never collect, they only aggregate.

If you care about each individual instance, you have an Entity.

The best way to model something like this is to use an Entity that has a Value Object component.  If I am maintaining a collection of Addresses, I do actually care that each is different – the trick is to find out why.  In my case I care because the Customer has an address history and I wish to maintain that history.  I model that like this:

public class HistoricalAddress : Entity
{
    public Address Address { get; set; }
    public DateTime? Start { get; set; }
    public DateTime? End { get; set; }
    public AddressType Type { get; set; }
}

Now the HistoricalAddress Entity lives in the Customer Aggregate…

public class Customer : Entity
{
    private readonly ISet<HistoricalAddress> _addresses = new HashedSet<HistoricalAddress>();

    public HistoricalAddress[] GetAddresses()
    {
        return _addresses.ToArray();
    }

    public HistoricalAddress GetAddress(Guid historicalAddressId)
    {
        return _addresses.SingleOrDefault(x => x.Id == historicalAddressId);
    }

    //...
}

… and I am free to edit, list, and delete them with ease.

The one caveat is when you are maintaining a collection of Value Objects that represent all possible values.  If you have a State Value Object you may want to represent a collection of all 50 U.S. States as a select list in the user interface.  This works fine and is programmatically possible, until you are interested in maintaining this collection.