In which layer should Specification Pattern objects be "new'ed up"?

Question

So, I've looked at some posts about the Specification Pattern here, and haven't found an answer to this one yet.

My question is, in an n-layered architecture, where exactly should me Specifications get "newed" up?

1. I could put them in my Service Layer (aka, Application layer it's sometimes called... basically, something an .aspx code-behind would talk to), but I feel like by doing that, I'm letting business rules leak out of the Domain. If the Domain objects are accessed some other way (besides the Service Layer), the Domain objects cannot enforce their own business rules.

2. I could inject the Specification into my Model class via constructor injection. But again, this feels "wrong". I feel like the only thing that should be injected into Model classes are "services", like Caching, Logging, dirty-flag tracking, etc... And if you can avoid it, to use Aspects instead of littering the constructors of the Model classes with tons of service interfaces.

3. I could inject the Specification via method injection (sometimes referred to as "Double Dispatch"???), and explicitly have that method encapsulate the injected Specification to enforce its business rule.

4. Create a "Domain Services" class, which would take a Specification(s) via constructor injection, and then let the Service Layer use the Domain Service to coordinate the Domain object. This seems OK to me, as the rule enforced by the Specification is still in the "Domain", and the Domain Service class can be named very much like the Domain object it's coordinating. The thing here is I feel like I'm writing a LOT of classes and code, just to "properly" implement the Specification pattern.

Add to this, that the Specification in question requires a Repository in order to determine whether it's "satisfied" or not.

This could potentially cause performance problems, esp. if I use constructor injection b/c consuming code could call a property that perhaps wraps the Specification, and that, in turn is calling the database.

So any ideas/thoughts/links to articles?

Where is the best place to new up and use Specifications?

Quartan

Answer 1

Short answer:

You use Specifications mainly in your Service Layer, so there.

Long answer: First of all, there's two questions here:

Where should your specs live, and where should they be new'd up?

Just like your repository interfaces, your specs should live in the domain layer, as they are, after all, domain specific. There's a question on SO that discusses this on repository interfaces.

Where should they be new'd up though? Well, I use LinqSpecs on my repositories and mostly ever have three methods on my repository:

public interface ILinqSpecsRepository<T>
{
    IEnumerable<T> FindAll(Specification<T> specification);
    IEnumerable<T> FindAll<TRelated>(Specification<T> specification, Expression<Func<T, TRelated>> fetchExpression);
    T FindOne(Specification<T> specification);
}

The rest of my queries are constructed in my service layer. That keeps the repositories from getting bloated with methods like GetUserByEmail, GetUserById, GetUserByStatus etc. In my service, I new-up my specs and pass them to the FindAll or FindOne methods of my repository. For example:

public User GetUserByEmail(string email)
{
    var withEmail = new UserByEmail(email); // the specification
    return userRepository.FindOne(withEmail);
}

and here is the Specification:

public class UserByEmail : Specification<User>
{
    private readonly string email;

    public UserByEmail(string email)
    {
        this.email = email;
    }

    #region Overrides of Specification<User>

    public override Expression<Func<User, bool>> IsSatisfiedBy()
    {
        return x => x.Email == email;
    }

    #endregion
}

So to answer your question, specs are new'd up in the service layer (in my book).

I feel like the only thing that should be injected into Model classes are "services"

IMO you should not be injecting anything into domain entities.

Add to this, that the Specification in question requires a Repository in order to determine whether it's "satisfied" or not.

That's a code smell. I would review your code there. A Specification should definitely not require a repository.

Toein

Not too sure if injecting a Repository into a Specification is a code smell or not. Check this StackOverflow discussion: link. The similarities between a Specification and a Domain Service can be very similar, especially if the rule you're tryign to enforce/prove happens to rely on getting information via a Repository first. – Quartan

You pass a specification to a repository, e.g. via FindOne(spec) or FindAll(spec). If you inject a repository into a specification you are in danger of creating a circular reference, which could lead to problems. – Toein

FYI I inject my specs into services when I need them. – Wurster

Answer 2

A specification is an implementation check of a business rule. It has to exist in the domain layer full stop.

Its hard to give specifics on how you do this as every codebase is different, but any business logic in my opinion needs to be in the domain layer and nowhere else. This business logic needs to be completely testable and coupled loosely from UI, database, external services and other non-domain dependencies. So I would definitely rule out 1, 2, and 3 above.

4 is an option, at least the specification will live in your domain layer. However the newing up of specifications depends really again on the implementation. We usually use depencency injection, hence the newing up of pretty much all of our objects is performed via an IOC container and corresponding bootstrapping code (i.e. we usually wire the application fluently). However we would never directly link business logic directly to e.g. UI model classes and the like. We usually have contours/boundaries between things such as UI and domain. We usually define domain service contracts, which can then be used by outside layers such as the UI etc.

Lastly, my answer is assuming that the system you are working on is at least some way complex. If it is a very simple system, domain driven design as a concept is probably too over the top. However some concepts such as testability, readibility, SoC etc should be respected regardless of the codebase in my opinion.

Hereof