Greg Young [MVP]

Always Valid

Greg — Fri, 22 May 2009 13:08:40 GMT

Jeff Palermo recently wrote up a blog post about “The fallacy of the always valid entity”. This post is a more thought out commentary to the ideas therein and could be better suited with a name of “The fallacy of the fallacy of the always valid entity”.

Jeff appears to be arguing with something that he for lack of better terminology just does not understand. He gives an example and then asks the question of:

“The fact that name is required needs to be context-bound. When is it invalid?”

This is referring to one type of validation that occurs within a domain. This is a validation to perform an operation. Generally speaking this type of validation is not performed by the object itself but is represented as observations of that object by another object. Jeff is right in that trying to make these things always valid makes no sense.

Of course no one in the “always valid object” camp has ever made such a statement. This brings us to the crutch of the argument … What do we want to keep valid?

==?

Not surprisingly some great people have dealt with these problems in the past.We can look at by going into philosophy (yeah boring I know) for a moment. Let’s say there are two horses a big Clydesdale and my friend’s daughter’s pony “samantha”. We have all seen the Budweiser commercials so we can imagine what the Clydesdale looks like but “samantha” is quite different. She is short, kind of thin, white with a black nose, and has her hoofs painted most of the time (likely due to her proximity to my friend’s daughter).

If we were to look at these two things we know that they are both horses. But they are still quite different, why is that? Plato put forth the concept of ideals, that there is somewhere an ideal horse which represents all of the recognizable traits of a horse. All horses can be descended from the one ideal horse, the ideal horse represents all of their common traits.

So you must be thinking how does this relate back to the original topic of objects always being valid? We have introduced a second type of validation!

Suppose we had a unicorn with no horn? Would it still be a unicorn? What about a cyclops with two eyes? These things are invariants of the objects (they belong on the concept of the ideal). If we were to have an object that did not meet these invariants it would in fact cease being the concept that we knew it as.

We run across these types of things regularly in our domains! Let’s imagine we are building grain silos … could we have a grain silo without a capacity? If we were writing poker software could we have a poker table without any seats? For a product application does it make sense to allow a sale line item without a product?

It can be quite useful for us to model our domains using invariants. The main reason for this is that it helps with DRY. Quite often we will see that nearly all or all operations require a certain thing to be true, as such the checks are run in many places. As an example a customer must have a name to place an order, they also must have a name to move, or to open a credit account. We could always be diligent to check that the customer has a name in various contexts or we can build into the customer object the invariant that the name will always be non-null. Invariants help us to narrow our thinking when we rationalize about our domain.

TDD will quickly lead you to the need for invariants. Consider when I have a BattleService that takes a parameter of a Cyclops … Without using invariants the first test I should be writing is should_throw_not_a_cyclops_exception_when_cyclops_has_two_eyes() … As soon as I find myself writing this test I should be seeing the language and realizing that I am being silly. In case that does not work I should at the least see that if I moved such a thing to be an invariant of my object that I could be saving myself code/tests elsewhere.

Now to bring this back to Jeffrey’s original misunderstanding of the always valid viewpoint, it is not that an object must always be valid for everything, there are lots of context based validations… Always valid means that you are not breaking your invariants.

Alt.Net Vancouver Edition

Greg — Wed, 20 May 2009 15:44:00 GMT

Registration is now open

Come to devTeach and stay for Alt.Net

Java vs .NET Developers

Greg — Tue, 28 Apr 2009 14:49:44 GMT

Davy Brion has an interesting post discussing his recent interviews with .NET and Java developers. I have to say that I agree with some of his assessments. Much of what we discuss in .NET is far more common in Java as Java has a far healthier community than Microsoft. You will find terrible developers on both side but the terrible developers on the Java side have more mainstream exposure to good ideas than on the Microsoft side.

The majority of the .NET community is fake as well, led by the leash by Microsoft. I remember in particular a discussion with quite a few people in Atlanta just after Katrina when I was there for a while where I was being laughed at and talked down to (the same tired arguments about sprocs) for suggesting the use of an ORM, these are the same people who today will reiterate the same arguments and push themselves as “ORM experts”.

How to we break out of this? I had great hopes for alt.net doing this but sometimes you feel like the engineer of a freight train who can see that truck 1/2 a mile ahead and has hit the breaks but is not hoping. I believe alt.net has at the least given the small few who were doing such things already a community upon which they can draw support from when they realize just how bleak of an abyss the .NET development world is. Over time new people will continue to populate alt.net and it will grow but because of the dynamics of the general community we will either need a revolution against Microsoft or Microsoft will need to lead the charge.

The drag and drop developer

A sub-theme to the post is the putting down of “drag and drop” developers. It is obvious that Davy in his scenarios values highly things like understanding DI and the SOLID principles. I agree that these things are very important, in some contexts!

“Drag-n-drop of pure visual components is usually not a big deal… drag-n-drop of data sources on pages or forms or whatever is a different matter entirely “

The typical arrogant developer viewpoint … likely the same kind of developer who would build DTOs on top of a domain layer to support a simple forms over data web application. There are contexts where dragging and dropping datasources can be extremely effective.

When people are attempting to use DDD one of the first things I tell them is not to, there are simpler ways and most applications do not justify the expense and complexity of DDD. Can we make a similar argument for development as a whole? Think about the systems that sharepoint is replacing today… Are they being “well crafted”? probably not but they are providing near immediate value at extremely low entrance prices. To help us further identify such systems, they are generally low risk and highly volatile.

The big problem with drag and drop development is not inherent within it but when it is applied to situations that it is inappropriate for.

Microsoft has made this possible with the creation and promotion of the drag and drop developer. These developers lack education, they are easy to bring in, they can produce value almost immediately, and cost a fraction of what a true engineer would cost. There is a vast number of systems that these developers can be extremely productive on while carrying little risk to the business as a whole. They also free up engineers to work on more interesting systems.

If we want to be effective architects one of our main goals should be to isolate these types of scenarios and build bubbles around them so we can use the lower skilled work force (at lower cost) without forcing our entire system to look like this. Remember that cost and scalability of a team is a non-functional requirement that we should be optimizing as well.

More on Repository

Greg — Fri, 24 Apr 2009 19:10:09 GMT

Oren has since responded so let me in turn respond. Its something that we will never agree upon because we have been in such different contexts.

He starts by saying

First, careful re-reading of the actual post doesn’t show me where I said that the repository pattern is dead. What I said was that the pattern doesn’t take into account advances in the persistence frameworks, and that in many cases, applying it on top of existing persistence framework don’t give us much.

I am sorry the exact statements were … “Repositories are a FAD" and “Repositories are the new Singleton”. I incorrectly used the term “dead” but the other statements are just as sensational to me.

Of course I have already rebutted the argument that is being presented that it doesn’t take into account the “advances in persistence frameworks” by bringing up the fact that it represents a LAYER/TIER boundary in an architecture. To this Oren replies:

Hm, I can see Greg’s point here, but I am not sure that I agree with him here. I would specify it differently .Service boundaries are procedural (be it RPC or message based, doesn’t matter). But a service spans both layers and tiers, and I am not going to try to create artificial boundaries inside my service. And yes, they are artificial. Remember: “A Repository mediates between the domain and data mapping layers…"

The boundary is not arbitrary or artificial. The boundary comes back to the reasons we were actually creating a domain model in the first place. it seems what Oren is actually arguing against is not whether “advances in ORMs” have changed things but that he questions the isolation at all. The whole point of the separation is to remove such details from our thinking when we deal with the domain and to make explicit the boundaries around the domain and the contracts of those boundaries. If you want further reasons read up on Hexagonal (Port/Adapter) architectures they are very well explained (note these are sort of like the “onion architecture” which was just a restatement of these ideas …. still waiting on that post to show the differences Jeff).

If we take Oren’s advice, we can store our data anywhere … so long as it looks and acts like a database. If that is not the case then oops we have to either

a) Make it look and act like a full database
b) Scrap our code that treated it as such and go back to the explicit route.

Just to be clear on this point … He has baked in fetch paths, full criteria, and ordering into his Query objects so any new implementation would also have to support all of those things. Tell me how do you do this when you are getting your data now from an explicit service?

Do all systems need to have ports/adapters around data access? No! but these same systems are likely good candidates to not be using a domain model but to instead be using one of the many simpler mechanisms out there. When you pop the bubble that has been built around your domain why not just do it again? who needs application services, we can just bind directly to domain objects …

Oren backs up his beliefs with YAGNI

I am going to call YAGNI on that. Until and unless I have that requirement, I am not going to think about that. There is a reason we have YAGNI.

Its not just about YAGNI its about risk management. We make the decision early (Port/Adapter) that will allow us to delay other decisions. It also costs us next to nothing up front to allow for our change later. YAGNI should never be used without thought of risk management, we should always be able to quantify our initial cost, the probability of change, and the cost of the change in the future.

In this case we have an initial cost which is the creation of thin repository classes that encapsulate our query objects (see Generic Repository post for example). These cost us nothing to create up front as compared to what Oren is showing… Literally minutes, especially when using command/query separation! What is the probability that we will have to work with a data store other than a database in the future? Say a tier boundary to a data service? This can change depending on your scenario … What is the cost if it happens, this is the key. the cost is large.

I think it becomes more obvious what the problem is when Oren defines a Repository as

A repository is a gateway to the actual persistence store. The persistence store itself may be another service, it is usually a remote machine, and the interface to that is by necessity pretty procedural. Trying to model a repository on top of that would by necessity lead us to procedural code. But that is a bad thing.

This is not a Repository this is generally a DAO. Repositories only give collection semantics to the domain, they SHOULD NOT contain the implementation I have gone through this in the past in a post I referenced in my last The Generic Repository. When you view a repository in this way things start to make more sense.

Continuing along…

A simple example would be a shopping cart, and the following commands:

AddProduct { ProductId = 12, Quantity = 2}

This require us to check if the product already exists in the cart, so we need to load the Items collections

Purchase

We can execute this with properties local to the shopping cart, so no need to load the items collection, this just charge the customer and change the cart status to Ordered

As I said, this is a simple example, and you could probably poke holes in it, that is not the point. The point is that this is a real example of real world issues. There is a reason why IFetchingStrategy is such an important concept.

Let me point out a large failure in logic here. You assume an impedance mismatch with a relational database that results in a much higher cost of getting the children with the parents. If I am using other mechanisms like say storing the ShoppingCart as a document in CouchDb that the cost will be nearly identical whether I bring back only the Cart or the Items.

Evans was very explicit in talking about aggregate root boundaries in that we need to consider them to be wholely loaded or not loaded at all. The whole concept of fetching strategies is nothing but a micro-optimization for a specific scenario … Relational Databases … If you are getting to the point where you absolutely need fetching paths you probably have your aggregate roots defined incorrectly and should use it as a smell to revisit them. I may have to revisit this in another post.

That is leaving aside that like all architectural patterns, CQS is something that you shouldn’t just apply blindly. You should make a decision base on additional complexity vs. required scope before using it. And in many applications, CQS, or a separate OLTP vs. Reporting models, are often not necessary.

I disagree with this and it shows a lack of understanding of CQS. I would recommend every system to apply CQS. At its root that is just a statement that you should have a separate layer for queries that builds DTOs off of projections as opposed to being built off of domain objects. There is no extra work to do or added complexity it is only different work in that you are putting the code somewhere else.

The idea of using a separate reporting model is allowed by CQS but it does not have to be used. In fact I would imagine most systems would not use but would instead be projecting their OLTP model, they will still end up with more control and a better overall system that they had projecting off their domain objects. If at some point later non-functional requirements dictate a need for a separate reporting model it can be introduced

Tricky Question

Greg — Fri, 24 Apr 2009 17:08:06 GMT

Someone gave me a tricky little question the other day that they had supposedly received in an interview at google and were stumped by. Its not really that tough but …

You have a circular queue of ordered items, come up with an algorithm for finding whether or not an item with the value of k is in it.

My first question: is the circular queue implemented as a list or within an array. Answer within an array (I was 1/2 expecting a problem to have to implement with a skip list for some reason).

A naive implementation would be to Iterate from head-tail end and then from beginning to tail, this will produce a result in O(n)

Can we do better? Spoiler below

We can do a binary search but it becomes a bit more tricky as things are not always sorted the way that we want. From above we know that if we have head or tail in a segment … the beginning of the segment to tail is sorted and we know that from head to the end of the segment is sorted. Coming though some other important examples.

Consider some examples when we go to split the data into 2 smaller arrays.

9 0 1 2 3 4 5 6 7 8
head = 1
tail = 0
3 4 5 6 7 8 9 0 1 2
head = 7
tail = 6

if head and tail are both on the same segment ... that side is not sorted properly

0 1 2 3 4 5 6 7 8 9
head = 0
tail = 9

If head is in one and tail is in the other then both are sorted perfectly.

If later we have neither head nor tail in our segments we know that they are sorted properly in their entirety.

By utilizing this information we can now trivially change our binary search algorithm to take into account the areas that may not be sorted correctly and issue a binary search!

Repository is Dead: Long Live Repository

Greg — Thu, 23 Apr 2009 14:28:41 GMT

The title sums up the argument in Oren’s recent post about repositories. Although we have had some discussions on twitter about that post I wanted to offer people a bit more of an analysis of what he has said and the pros/cons of such a strategy. His post was originally intended to be an “alternative to the repository pattern” which he believes “is dead”.

His new solution to the problem is to instead use query objects that are passed into the repository to remove the "complexity”. Of course this is far from a new idea in fact it has been discussed on this blog in Specification or Query Object and also in The Generic Repository where pretty much the exact same idea is put forward ( If you have not I strongly recommend reading The Generic Repository as it uses an almost identical method (except the query objects are used in the Repository implementation which composes a generic repository that it passes query objects to)). The concepts are also discussed in Domain Driven Design itself (they are just called specifications instead of query objects).

What is particularly annoying is the sensationalism associated with this post. It is extremely odd to argue against a pattern by suggesting to use the pattern eh? The suggested way to avoid the Repository pattern is to use the Repository pattern which shortening the definition he provided

Provides the domain collection semantics to a set of aggregate root objects.

So now that we have determined that he has not actually come up with anything new and is actually still using repositories let’s reframe the original argument into what it really is.

FindCustomer(id)
FindCustomerWithAddresses(id)
FindCustomerWith..

Oren has an issue with named query methods on a Repository interface. I will ignore the arguments provided by him and provide a simpler better argument for why you SHOULD NOT use these types of methods.

The Open Closed Principle. Versioning a Repository that uses these types of methods is extremely difficult. When I want to add a new method, or change an existing one I am changing the original contract. If I move these to a single method that takes a Query object I can change/add/remove queries without touching my Repository contract. In other words, we are simply applying SOLID to the repository interface.

Now we all know that following the Open Closed Principle amongst others is good right?

I would answer that question with “Yes in general following the SOLID principles leads to better Object Oriented code”.

I am sure I have left a few fairly confused at this point as I argue against my own point but I am leading to something important. The problem here is that the Repository interface is not necessarily Object Oriented. The Repository represents an architectural boundary, it is intended to be a LAYER/TIER boundary. Generally speaking when we define such interfaces we define them in a procedural manner (and with good cause).

Analyzing the situation given of a CustomerRepository what would happen if we were to want to put the data access behind a remote facade? With the simple procedural boundary of named methods, we would just go create a remote facade (say a webservice) and we would pass through the calls. What would happen though if we used the “other” Repository interface that is being suggested? Well our remote facade would need to support the passing of any criteria dynamically across its contract, this is generally considered bad contract design as we then will have great trouble figuring out and optimizing what our service actually does. With the explicit contract we have to explicitly add or change the contract and we know when things are being added that may need to be optimized. I am quite sure everyone has dealt at some point with the service that had 1 method and could do anything typically they take and receive strings my favorite are the ones you pass SQL to and they return you random XML (usually a serialized data table) …

One could argue against me here by saying that they don’t consider their Repositories to be LAYER/TIER boundaries… Well, I am sorry but you are using the pattern incorrectly then. If you don’t want a LAYER/TIER boundary don’t have one just use nhibernate directly … At this point you probably shouldn’t have a domain either though … If your system is complex enough to justify the cost of creating a good model why are you trying to optimize the < 2% spent on Repository abstractions?

After this Oren brings forth another very interesting issue that led him to his epiphany of killing Repositories.

It get worse when you have complex search criteria and complex fetch plan. Then you are stuck either creating a method per each combination that you use or generalizing that

I have had this smell in the past as well but instead of destroying the layering I am building into my domain (with good reason, see DDD by Evans for why) I went a completely different route. I noticed very quickly that it was by some random chance that my fetch plans were being different. I had a very distinct place where things were different, I needed very different fetching plans between when I was getting domain objects to perform a writing behaviour on them as opposed to when I was reading objects to say build a DTO.

This realization is what led me to command and query separation, the creation of a separate layer to process read->DTO transformations and to no longer use my domain repositories for this purpose. I should point out that for the read layer, what is being shown by Oren is a great way of implementing it. I won’t go into a large talk on command and query separation here (there is a good video from the european van and hopefully the QCon SF session will be up soon)… but if you apply command and query separation you will have almost none (read: none) read methods on your repositories in your domain.

Continuing along, Oren randomly puts forth the gem of:

A lot of people use it, mostly because of the DDD association. I am currently in the opinion that DDD should be approached with caution, since if you don’t actually need it (and have the prerequisites for it, such as business expert to work closely with or an app that can actually benefit from it), it is probably going to be more painful to try using DDD than without.

It being everyone has heard pretty much every real DDD practitioner saying this for years, I am really unsure why it has taken so long to figure this out? This also begs the question of what systems actually need or are suitable for DDD but that’s another day and another post.

Blog

Greg — Tue, 31 Mar 2009 04:37:07 GMT

Found a very interesting blog today.

http://jonathan-oliver.blogspot.com/

There is DDDD stuff here, some conjecture, some good analysis, some complete horse shit! but a LOT of interesting discussion! It will take me a while to read through it all.

My Horrible Lie

Greg — Thu, 19 Mar 2009 21:14:48 GMT

I have to admit that when I first started writing about DDDD I felt the need to separate its concepts from DDD. The reason for this is that the concepts being discussed were not in the mainstream of DDD. It needed to be segregated so that people could differentiate between the ideas....

Now to let everyone in on the secret. This was a deception on my part.

DDDD is DDD.

Today's VAN

Greg — Mon, 09 Feb 2009 16:26:00 GMT

As some may know the VAN last week was cancelled due to some technical difficulties. It will be happening this afternoon.

http://elegantcode.com/2009/02/02/european-virtual-altnet-meeting-rescheduled/ has the detailed information. I believe that all of the technical difficulties have been resolved as I now have a windows machine that can connect.

Cost?

Greg — Mon, 09 Feb 2009 15:10:00 GMT

In response to someone’s comment of:

“writing all of these message objects takes a lot of time”

We have come to a very very very important question. What is the cost of Command Query Separation and Messaging in general in comparison to say a more traditional architecture?

I would like to look at this from two perspectives. The first perspective is that of the actual cost of using the types of methodologies I bring up. In other words what physical overhead can we see as a result of making the choice?

The first cost that people cite to me is that you have to create messages. There are generally more messages than there would be say DTOs because messages represent behaviors that are happening and carry the context of the operation to the server. Generally speaking you can have multiple behaviors for each piece of changed data so you will end up with more messages than simple DTOs.

So admitting that it requires us more time to type messages let’s make an attempt to quantify that time. Creating a message does not really take that long (especially if you use resharper). But if you are in a situation where the optimizing the typing of a message (generally around 1 minute) becomes an important optimization to you in terms of increasing your productivity I either would suggest you rethink using a domain layer as a whole or that you take advantage of code generation as you are likely in a fairly simplistic CRUD scenario.

The next cost is the actual creation of a “Read Layer” to perform querying. To remove any overhead of synchronizing models let’s for a moment forget about having a separate database to support the reads and assume that the queries are hitting say views on the normalized database that our domain writes to. In this case there is actually no overhead, it is simply a matter of where we are placing the code. Is the code in a repository or is it in a reading provider in another model?

I believe that this shows there to be a rather negligible cost associated with the use of such a model. There is however a small cost, this cost however I believe only exists when one looks at the system in isolation.

Systems in the real world very rarely run in isolation. It is far more common to see a mesh of system interactions. The point of sales context talks to the accounting context and to the warehousing context. The warehousing context talks to the inventory context and to the accounting context. The accounting context talks to the warehousing context, the inventory context…. You get the point.

The unfortunate reality is that it is quite common that you spend more money making everything talk together than building the things in the first place. One benefit that has not really been discussed of having a message based system is in terms of integration. It is far easier to integrate such a system into system of systems because everything that is happening within it is already available! We also tends towards a “subscription/denormalize” method for integration which leads us towards higher availability.

With a more traditional architecture we tends towards integration through databases. Integration through databases is a scary idea and should be avoided in all but the most naïve cases. If we try to make the traditional architecture not integrate through data we often end up spending more money that something like messaging from the beginning would have cost us in the first place!

When analyzing the costs of something make sure that you are looking at a wide enough perspective in your organization. Sometimes things that seem locally inexpensive are globally quite expensive (jeeze now I sound like Al Gore talking about global warming).

Big Ball of Entropy?

Greg — Thu, 05 Feb 2009 19:22:00 GMT

Just a quick thought, the comments should be interesting on this one.

What is the relationship between the Big Ball of Mud and Entropy?

Are all systems of a reasonable level of complexity destined to become Big Balls of Mud?

Do the economics of our industry drive things towards a Big Balls of Mud?

VAN Talk TODAY

Greg — Mon, 02 Feb 2009 14:54:00 GMT

I will be doing a talk today for Alt.Net Europe's VAN program

You can find out more information on the talk including the livemeeting address here http://elegantcode.com/2009/01/29/european-virtual-altnet-meeting-on-02022009/

I will be talking about command query separation in DDD based systems. There has been a lot of talk recently about this on the DDD list and after explaining the basics of how things can work I will address some of the questions that have come up.

Hope to "hear" you there

Architecture Talk

Greg — Tue, 27 Jan 2009 17:51:00 GMT

When: 16/2/2009 18:15

Where: Microsoft Montreal

Link: Here you go

What:

Tout ce que vous avez toujours voulu savoir sur l'architecture - Sans oser le demander

L'architecture logiciel consiste à modéliser et à appliquer des heuristiques pour simplifier le système à construire. Cette présentation fournit une introduction à l'architecture logicielle de même qu'un parcours pour permettre au développeurs professionnels d'évoluer de programmeur à architecte. Nous discuterons des types de problèmes que les architectes logiciels essaient de résoudre tout en respectant la réalité économiques du monde logiciel. À la fin de cette présentation, vous comprendrez pourquoi une GROSSE BOULE DE BOUE, l'architecture logiciel le plus souvent déployée, peut être un bon choix architectural.

Everything you always want to know about architecture - But were afraid to ask

Software architecture is about modeling and applying heuristics to simplify the system to build. This presentation provides an introduction to software architecture as well as a roadmap for professional developers to evolve from coder to architect. We will discuss the types of problems software architects try to solve while respecting the economics of the software world. At the end of this presentation, you will understand why a BIG BALL OF MUD, the most frequently deployed software architecture, can be a good architectural choice.

Note: C'est ma troisieme semain a Montreal, je ne pense pas que je vais parler en francais :)

Welcome to the Anemic Age

Greg — Thu, 22 Jan 2009 20:07:00 GMT

Just a quick run by posting. It seems that all the cool kids are now building apps using anemic domain models

The recent document Two tier application scenario (REST) from MS P&P is a good example. While I am picking on P&P here this is by no means an uncommon piece of advice please bear with me that this is GUIDANCE being put out. Update as if that was not bad enough the same guidance also makes up the Three Tier Web Application Guide it looks as if this will just be Microsoft's new guidance.

I love that "behaviors" are described in a single line as being "transaction script services".

I have been seeing this trend for a while now. I had thought that we had all learned our lessons years ago about anemic domain models.... oh wait that was the java community it will be different this time.

I think part of the problem is that coming up with the RESTful architecture is so much more neat for an ~~astronaut~~ architect because its happily generic and can be described well in an architectural document or even better by a framework. I mean to deal with those "system behavior transaction scripts" you might actually have to talk about ... the business, and you can't write a simple document/framework to describe how to handle it.

As this guidance (like most) will be followed blindly by 90+% of people who read it, I would like to be the first to welcome you to the Anemic Age. Procedura code is dead, long live procedural code!

Update: Great quote

"What strikes me most about the P&P article is that the seems like it would perform best in a forms over data app. But if you really have a forms over data app, then the architecture is way too complex.". Bingo, I actually had a similar conversation with someone else today.

DDD: Specification or Query Object

Greg — Tue, 20 Jan 2009 19:06:00 GMT

One of the nice benefits of a Specification is that one could write some code like the following:

IEnumerable<Customer> customers = CustomerRepository.AllMatching(CustomerSpecifications.IsGoldCustomer);

Writing code like this has allowed the developer to reuse a specification from the domain within their repository as a method for querying. While this may seem to be a good thing at the outset this mentality introduces a host of problems.

Performance
The first and largest problem that one will run into when dealing with this type of API is that the Repository is necessarily a leaky abstraction. The GoldCustomerSpecification is a piece of code, it represents a predicate for whether a single customer is or is not a gold customer. In order to return a set of customers that represents all of the customers matching the GoldCustomerSpecification the repository will need to run the specification on every customer.

Before looking at other types of infrastructure consider the ramifications of needing to run the specification on every customer that is in an “in memory” repository. The operation is necessarily O(n). As most learned in university, O(n) is a bad place to be as n gets large.

Even more unfortunate is that once this is considered with infrastructure the constants that we deal with grow. If one were using say a database now the work involved is not just running the specification on an existing object but hydrating the objects (and likely many of their children) in order to even be able to test the predicate upon the objects.

When dealing with such queries one prefers to be able to EXPOSE and then INDEX criteria allowing the operations to be treed/hashed resulting in algorithmic costs of O(log n) or less.

Weak Contracts
Beyond the performance issues there also exist further issues that will affect the development team. By exposing a method such as a “AllMatching” from the repository the importance of the contract offered by the repository is minimized.

Repositories represent a contract to a data store. If one uses all named operations upon the repository (as explained in [The Generic Repository]) one creates a strong contract to their data source. When it becomes time to analyze the system from a database performance perspective it is extremely easy to get a list of the queries that a given repository can run because they all originate within the repository itself as opposed to in other code.

Sometimes …
On the read side of your domain (a different layer if you use cqs) you want clients to be able to pass query objects directly to your repositories. Keep in mind that these are not the repositories on the transactional side (read: domain) but are supporting the complex reporting behaviors needed. It is often times not possible to completely isolate every type of report you may like to run (but you should still try to do this where possible as the strong contract has benefits).

I wanted it for a reason!
Having looked at the negatives there are two major positives to being able to use specifications within the domain.

Being forced to create both a query object and a specification for every predicate that is used in both places causes code duplication. Anytime there is duplication of code in a system there is a chance for the implementations to split. Someone may change the IsGoldCustomerSpecification to become a slightly new meaning but may forget that there is also a query object that is being used by a repository.

The creation of the two objects also necessitates a problem in the ubiquitous language. By creating the two objects there now exist two concepts in the ubiquitous language for technical reasons to represent what the domain expert considered to be a single concept. This may not sound at first like a big problem but it is artificially changing the domain language and because it is it opens the door to divergence in the concepts deliberately by the domain expert. If the terms diverge it becomes a very weird place in terms of conversation and will require a further divergence (renaming) of at least one of the terms.

The Solutions?
As has been explained, the Specification or Query Object problem can be quite troubling but there are many possible solutions that have been implemented in the past. All of the solutions share a common theme.

Composite Specification
The basic issue is that what is “inside” of the executable specification object cannot be easily accessed to be translated into a query object. By representing a specification as a tree of composite objects one can easily write a translator to convert the tree to the query language of choice.

This solution while good can be fairly expensive in terms of either initial cost and/or complexity of learning a tool if you use someone else’s as you will generally be forced to build up specifications using some form of a “fluent” API. This may evolve to be an internal DSL.

A Custom External DSL
A natural continuation to the composite object solution is to no longer represent specifications as code within my language of choice but to instead represent all specifications within a DSL. This solution hits the core of what is needed in any solution, an abstract version of what the specification means so one can look through the metadata to translate dynamically the specification to a query object when necessary.

This solution does however offer some distinct disadvantages. The largest of the disadvantages is that it requires a large amount of technical expertise at the time of the implementation to create and maintain an external DSL. Since the goal of the DSL is to allow access to an AST representing the code as opposed to the code itself and it will be “compiled” against multiple sources, the DSL would necessarily have to be external as most modern languages C#/Java as an example did not support such things.

The technical issues of creating the DSL could have been mitigated by the creation of an open source project to maintain such a DSL. There would still have been problems however in that developers would still now need to understand two languages (and likely two or more processes of code generation). Requiring developers to understand more tools is generally best avoided in preference of solutions that do not require the learning of new tools.

Linq?!
Recent developments at Microsoft have created LINQ that is essentially an internal DSL that does the same task as the previously discussed external DSL. It does however get around many of the issues with an external DSL by its being an internal DSL.

To begin with, there is no technical hurdle to implementing LINQ. Microsoft has already done it and has stepped up to insure that it is supported for the foreseeable future making it a safe choice to bring in on projects. Microsoft has also added it directly to languages such as VB.NET and C# which prevents developers from needing to learn a new tool in order to be able to use it.

The basic workings of Linq is to allow an expression to be expressed as an expression tree (a type of AST). This expression tree can as in the DSL example be translated to multiple formats.

Hint: Query Objects and Specifications although closely related are quite different with varying needs. Although often confused it is imperative that their differences be understood. If available, language tools such as an internal/external DSL or Linq can be used to allow specifications to be expressed as expression trees allowing them to be translated as query objects as opposed to only as executable code.