Design Pattern "Specification"

When attempting to comprehend DDD, you will surely come across this pattern, which is often closely used together with another, no less interesting, “Repository” pattern. This pattern provides the ability to describe requirements for business objects, and then use them (and their compositions) for filtering without duplicating queries.

Example

For example, let's design a domain for a simple group chat: we will have three entities: Group and User, between whom there is a many-to-many relationship (one user can be in different groups, there can be several users in a group) and Message, which is a message which the user can write in any group:

public class Member { public string Nick { get; set; } public string Country { get; set; } public int Age { get; set; } public ICollection<Group> Groups { get; set; } public ICollection<Message> Messages { get; set; } } public class Message { public string Body { get; set; } public DateTime Timestamp { get; set; } public Member Author { get; set; } } public class Group { public string Name { get; set; } public string Subject { get; set; } public Member Owner { get; set; } public ICollection<Message> Messages { get; set; } public ICollection<Member> Members { get; set; } } 

Now imagine that you write two methods in the Application Service:

 /// <summary> ///     ,      /// </summary> public ICollection<Member> GetMembersInGroupFromCountry(string groupName, string country) { } /// <summary> ///     ,           /// </summary> public ICollection<Member> GetInactiveMembersInGroupOnDateRange(string groupName, DateTime start, DateTime end) { } 

Implementation 1 (bad):

You can allow services to build queries on top of the repository themselves:

 public ICollection<Member> GetMembersInGroupFromCountry(string groupName, string country) { return _membersRepository.Query.Where(m => m.Groups.Any(g => g.Name == groupName) && m.Country == country); } public ICollection<Member> GetInactiveMembersInGroupOnDateRange(string groupName, DateTime start, DateTime end) { return _membersRepository.Query.Where(m => m.Groups.Any(g => g.Name == groupName) && !m.Messages.Any(msg => msg.Timestamp > start && msg.Timestamp < end)); } 

')
Minuses:
Opening the request object to the outside of the repository is comparable to opening a store selling weapons without requiring a license from customers - you simply do not follow everyone and someone will surely shoot someone. I’m deciphering the analogy: you’ll almost certainly have a lot of similar queries on top of Query in different parts of the service (s) and if you decide to add a new field (for example, filter the groups based on IsDeleted, and users on the basis of IsBanned) and take it into account for many selections - you risk missing a method.

Implementation 2 (not bad):

You can simply describe in the repository contract all the methods that are needed for services by hiding filtering in them, the implementation will look like this:

 public ICollection<Member> GetMembersInGroupFromCountry(string groupName, string country) { return _membersRepository. GetMembersInGroupFromCountry(groupName, country); } public ICollection<Member> GetInactiveMembersInGroupOnDateRange(string groupName, DateTime start, DateTime end) { return _membersRepository. GetInactiveMembersInGroupOnDateRange(groupName, start, end); } 

Minuses:
This implementation has no shortage of the first, but it has its own - gradually your repository will grow and swell and, eventually, will turn into something poorly supported.

Implementation 3 (excellent):

Here the Specification comes to help us, thanks to which our code will look like this:

 public ICollection<Member> GetMembersInGroupFromCountry(string groupName, string country) { return _membersRepository.AllMatching(MemberSpecifications.Group(groupName) && MemberSpecs.FromCountry(country)); } public ICollection<Member> GetInactiveMembersInGroupOnDateRange(string groupName, DateTime start, DateTime end) { return _membersRepository.AllMatching(MemberSpecifications.Group(groupName) && MemberSpecs.InactiveInDateRange(start, end)); } 

We get a double profit: the repository is clean like a baby's tear and does not swell, and in the services there is no duplication of requests and the risk of missing a condition somewhere, for example, if you decide to filter groups everywhere based on IsDeleted, you only need to add this condition once in the MemberSpecs specification .FromGroup

Pattern implementation

Martin Fowler (and Eric Evans) proposed the following specification interface:

 public abstract class Specification<T> { public abstract bool IsSatisfiedBy(T entity); } 

The guys from linqspecs.codeplex.com made it more repository-friendly (its specific implementations based on EF, nHibernate, etc.) and even serializable:

 public abstract class Specification<T> { public abstract Expression<Func<T, bool>> IsSatisfiedBy(); } 

Thanks to the ExpressionTree repository can parse the expression and translate it into SQL or something else. The basic implementation with the basic logic elements looks like this:



Now we need only for each entity (aggregate) to write a static class containing specifications. For our example, it will look like this:

 public static class MemberSpecifications { public static Specification<Member> Group(string groupName) { return new DirectSpecification<User>(member => member.Groups.Any(g => g.Name == groupName)); } public static Specification<Member> Country(string country) { return new DirectSpecification<User>(member => member.Country == country); } public static Specification<Member> InactiveSinceTo(DateTime start, DateTime end) { return new DirectSpecification<User>(member => member.Messages.Any(msg => msg.Timestamp > start && msg.Timestamp < end)); } } 

Conclusion

This is how we got rid of the duplication of conditions even in our small example, but we can truly appreciate it on large projects with complex logic. This is DDD’s misfortune, that it is always explained with small examples and it’s hard to get rid of the idea that all this is over-engineering.

Links

An excellent example of where the implementations of the specifications were taken is located here . Just pay attention to this article in the habr with a list of literature on DDD.