I would like to know more about the Specification Pattern, as it is described in Eric Evan's book "Domain Driven Design".

One of the key points Evans makes is that the domain model contains all important business rules (logic and behavior).

The DDD tactical patterns in the book describe how domain knowledge can be encapsulated in an object oriented way using Entities and Aggregates.

The specification pattern helps to encapsulate a piece of domain knowledge into a single unit.

If I want to use the Specification pattern and have different uses of it and evaluate a constant logic in several places, such as before the Application Service as Input Validation and inside the Entity for its processes as invariants, but if I want to keep the domain logic inside itself, how should I implement it?

To me, it looks like specification is not a pattern that can be used with the DDD approach and the OOP paradigm, and it is more useful for the functional programming paradigm.

Is my understanding correct?

  • A 'domain model' in Eric Evans' DDD book is conceptual; the book itself is about an approach for analysing requirements and capturing information in a way that helps everyone on a project communicate with each other. Any such technical concerns about design patterns or writing code exists beyond the realm of DDD because implementation isn't relevant to the process of analysing requirements or defining a domain model (A domain model should be totally agnostic to any possible implementation detail, so should not contain technical/programming concepts). Feb 8, 2023 at 8:41
  • 1
    Perhaps you can rewrite the question and leave out any references to DDD. Your question seems to be about the specification pattern in relation to object oriented programming and in particular about the role encapsulation plays when these concepts are combined.
    – Rik D
    Feb 8, 2023 at 16:59
  • @BenCottrell: sorry, but I don't buy what you wrote about a "domain model agnostic to any possible implementation". DDD is about designing models that work in reality and can be effectively implemented using real tools and frameworks, and Evan's has a clear focus in his book on verifying his concepts with example implementations. That is specifically true for Specification chapter in the DDD book.
    – Doc Brown
    Feb 9, 2023 at 19:41
  • @RikD: there is a full chapter in Evan's DDD book with the title "Specification", and that is what this question is about. I don't think it makes sense to remove the DDD references in this question.
    – Doc Brown
    Feb 9, 2023 at 19:43
  • See also this article written by Evans and Fowler: martinfowler.com/apsupp/spec.pdf Feb 10, 2023 at 1:16

1 Answer 1


It is easy to miss the point what the concept of a Specification is about, because there are so many bad articles floating around in the web.

Before the question was edited, you originally wrote:

And on the other hand, DDD says that this domain knowledge or logic must be inside the entity itself.

Em, no. Entities are not the only elements inside a domain model which can carry domain knowledge. Value objects can too, and the Specification objects as described in Evan's DDD book are value objects - specifically value objects which carry boolean logic. Entities together with related value objects form aggregates, these are the places where the domain knowledge lives.

I recommend to enhance your understanding by starting with this ~20 years old article written by Martin Fowler and Erik Evans about "Specification" mainly as an Analysis pattern, but also with some suggestions for possible implementations.

For simple cases, Specification objects can simply be seen as some kind of helper objects. They may appear when you see the need to refactor some boolean logic out of a domain entity, for example because you want to fight against an entity becoming a "god object", or because you see an opportunity to create an object where a piece logic can be unit tested on its own. Still the Specification does not have an identity on its own, it belongs to some domain entity, even if the code is not placed inside the same class. This is what the former article calls "Hardcoded Specification."

The logic might not be completely hardcoded, it could be also exchanged at run time by implementing Specification objects using the strategy pattern, or by introducing some parameters (which the article calls "Parametrized Specification").

For more complex cases, implementations like "Composite Specification" might be useful. This Wikipedia article shows a possible implementation. One confusing part here is that it just calls it "Specification pattern". This title is definitely too general, or the article itself way-too-specific, since it shows only the Composite approach. Another confusing part is that is presents a lot of code for the required framework, without making the purpose of the Composite Specification clear. The benefit of such a complex approach is to be able to modify certain business rules freely at run time. Hence it can be modified by input or configuration from some user, or by some external data source. This benefit comes for the price of having to build and use a mini-framework of "composite elements" around it.

"Composite Specification" is essentially a way to combine predicates (boolean functions) by standard conditionals AND, OR, NOT at run time. What you correctly have noted: this is indeed a functional task, and it can surely be implemented by functional means with less code and less overhead than with pure OO means.

Still creating specification objects makes perfectly sense in an OO and/or DDD context. Today, 20 years later, functional elements have become more and more popular in most major programming languages. Hence I think it should be easily possible to use a multi-paradigm approach and implement Specifications in a domain model using higher order functions or closures instead of ordinary value objects. Still this would be DDD and OO (with some functional "goodies"), I don't see any contradiction in this.

  • (Completely rewritten after I read the "Specification" chapter in Evan's book again - I think this is necessary to understand the question correctly.)
    – Doc Brown
    Feb 9, 2023 at 21:26
  • I also re-read the chapter and tried to clarify the question even further. Unfortunately I can upvote your answer only once, I already upvoted it before the edit but now it's even better.
    – Rik D
    Feb 9, 2023 at 23:07
  • @RikD: many thanks. May I suggest you upvote the question? Helps to prevent closage / deletion.
    – Doc Brown
    Feb 10, 2023 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.