Good discussions indeed!  From my perspective, a lot of these DDD approaches and the domain model pattern itself, are just good object-oriented design practices in the first place that help adhere to OOD principles.  [butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod]

For instance, the Specification pattern, while really nothing more than an implementation of a strategy pattern, can be very useful in a domain model.  Very interesting logic can be encapsulated in these tiny highly-cohesive classes (i.e. calculations, policies, criteria, etc.) that can really help to stay as close to SRP & OCP as possible (with OCP arguably being one of the hardest principles to adhere to in a real world system).  Not to mention it makes testing these little jokers in isolation very easy.

Are you guys making use of Specifications?  If so, I'd be curious as to how far you take it?  (And yes Joe, I know, "it depends"...)  :D

Well, yeah, the search criteria data itself would really just be a value object, but the ability to chain together multiple criteria together can be attractive.

For example, a tip I picked up from JP was to create your own IRichList<T> interface and overloading Find<T>() and FindAll<T>() to take in an ISpecification<T> implementation.  Then you can create a nice mechanism for chaining together specifications when passing them in like:

addressBook.FindAll(PersonsOverTheAgeOf16.And(PersonsWhoLiveInTexas))

Simple example, but you get the point.  A better example can be found here:  [devlicio.us/.../the-specification-pattern.aspx]

Ok, Ok, already.  Guess it's official now...  :)

@Joey

>"For instance, the Specification pattern, while really nothing more than an implementation of a strategy pattern..."

Well that depends ... :-)  The model specification as it relates to DDD purpose is to make implicit engineering concepts explicit for the "Ubiquitous Language".  The OOP strategy pattern is a form of the EPP specification pattern but within a Domain Model the "Specificaton" is a term reserved for predicate operations that allow for greater incite to be captured towards to model.

For instance the method  "isCool" evaluates height, dress and odor of a person.  In this case the "CoolPersonSpecification" object can be talked towards in a model and everyone understands what it does.  Does it use a strategy pattern maybe or is it simply a switch statement encapsulated to provide greater incite? Perhaps.  The point is (drum role) it depends!  Simplicity first, patterns second.  If all you are doing is evaluating 3 criterion maybe a strategy pattern is overkill.

The important question to ask is, "When I mention the Cool Person Specification does everyone understand what I am talking about?"  If they don't then go back and see if it is even applicable in the domain or does it belong outside the domain layer?

"Do you take the blue pill or the red pill?"  :-)

Awesome Joey!

Ahh, ok.  I see what you mean.  BTW, I'm still working my way through the official Evans book, so forgive me if my application of DDD is not quite in-line.  :)

So I'm currently encapsulating certain calculations into little strategy classes because I already know that the details of *how* the calculations will work is going to change (as in next week).  So in this case, my thoughts are that by encapsulating frequently changing logic like this into small isolated classes it will keep me from having to keep modifying my domain objects themselves if all I need to do is introduce a new *implementation* of a certain calculation.

As to whether this is just a simple OOP strategy pattern or a DDD specification... well, guess it depends...  :)

Thanks for the correction Joe!