Specification Pattern Implementation

We've been discussing specifications as a way of expressing what objects we need to get back from repositories and we found lots of interesting articles:

1. In Memory Filtering Of Repository Results - This approach seems to get all the objects then use the specification to filter in memory.
2. Linq - There must be loads of other posts on this sort of things but this ones very good.
3. .NET Example - I personally have a few issues with this approach, its not high enough in abstraction but I presume you could build quite abstract specifications on top of it.
4. DDD Discussion 1 - Mainly focusing on what Linq brings us.
5. DDD Discussion 2 - The reality of Query Object v Specification using current technologies, its a mother of a discussion but interesting none the less.
6. Ayende - proposes creating ICriteria based queries from the domain. Personally I minimize calls from the domain to the repositories, just to make testing easy. In general though although we use NHibernate our repositories don't expose NHibernate specific features on the interface, partly for simplicity but mainly so if we did need to walk away from NHibernate we'd have some chance of managing to do it.
7. Ayende 2 - Doesn't really give much away.

My reading of the whole thing is that specifications are great for validation rules (we use this approach), great for selecting things from in memory collections and great when constructing new objects in factories.

However trying to use a single specification that can evaluate in memory objects and that can spit out the necessary HQL/ICriteria/SQL for use by the repository is not going to be simple. The best I think most people can do is to have a method to evaluate in-memory objects and an HQL or query object to do the equivalent against the DB. Or wait for Linq and see how that all fits in.

Anyway on the more general topic of the specification pattern there are some great links, two of which are:

1. Fowler / Evans - Two experts at work. I just love the way they write, with the +/- approach, every time I read one of their documents or a section in their books I learn something.
2. In Memory - Very nice approach to using it for using specifications to make decisions, .NET specific. Great post.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Titan - Another DI Approach

Another DI approach called Titan is now in beta, this time with a focus on simplicity.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

More Dependency Injection Stuff

There seems to be increasing talk abotu dependency injection so I've been reading about it, this is in particular is a superb article about it. I'm still not 100% sold on it for our application though for a few reasons:

1. I find the service locator and registry approaches just as testable and a good deal simpler.
2. We don't really want to be doing some of the clever things that DI would allow, such as using the decorator pattern for repositories and then adding in functionality by reconfiguring.

Still its a great topic and anything Oren writes is worth reading.

Fowlers original article on it is also obviously worth a look.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Interfaces For Domain Classes

Its amazing what you find on the Web, I did a search to see how people handle mocking out dependencies within the domain (for example mocking a Customer when testing an Order) and came upon loads of interesting DDD articles.

The first one covers whether domain classes should use interfaces, I agree with the author and view interfaces as something we should only add when they really add value.

For example if I create an IOrder interface is that really improving my design? It might make mocking easier but in my view its only worth creating the interface if it has been defined for a real client of the class. So if we have multiple types of order, or if we want to break the complex interface of an Order down into multiple seperate (and targeted) interfaces then great. However if it is just so I can use mocking to get in mock orders, or because I believe that interfaces really server as good contracts, na. Not when it complicates the domain so much and hides the places where interfaces really are useful.

As someone correctly says in the comments for the post the need to version interfaces does not necessarily apply to the sorts of interfaces you define in the domain. Sure the interfaces are published, but if you only have 1-3 applications using the interface then surely its easier to change them.

I'm also not 100% sure I agree about intention revealing exceptions. In our case when you ask a domain object if its invalid it will do some validation and return a collection of BrokenDomainRules (or something like that). Inside the collection the rules are intention revealing (e.g. DateIsDuringWeekRule) but the exception that you get when you try to do something without meeting the preconditions (maybe make a state change that the object is not ready for) is just a DomainValidationException. The exception does contain the broken rules though, for me thats enough as its the rules (not the exceptions) that I think are part of the domain language.

Having said all that this is also a good post, pushing for using interfaces in the domain. The truth is I think interfaces are useful if they're cut down and design from the clients perspective, as always.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Dependency Injection And The Domain

I've always been slightly against using DI to inject repositories into the domain on the code base I work on, because I think it increases complexity and obviously you are then coupled to the DI framework. In thus use a custom approach based on Fowlers' Registry Pattern.

Having said that there is an interesting discussion of the topic in an excellent blog entry by one of the contributors to the DDD forum, and the auto mocking container approach would make using DI and integrating it into testing easier.

I still think the registry based approach was the correct one for us, its not particularly new or fancy but it works well.

Having said that I guess it is worth considering Windsor, or something like Microsofts DI approach, as an alternative...though I still prefer that my domain and its unit tests have no association with something like Windsor as I want to make the domain and its tests as simple as possible.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Team Project - Areas And Interations

Interesting blog entry about how to structure your team projects.

Good on Eric Lee for bothering to publish about it but the lack of guidance from Microsoft about how to use Team System is a major issue, and even now I don't really know how to apply the structure he is suggesting.

In general I think that Microsoft are making it difficult for the average team trying to use Team System well because they just haven't told us how.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Ruby On Rails Screencasts

Finally got round to listening to the ruby on rails screencasts. The one about the database migration was very interesting. You have to put up with the noise of the keys on the keyboard being hammered and a bit of sniffing but it is worth it to see how it works.

In general although ruby on rails interests me I'm not going to be giving up on DDD any time soon, I still think viewing your domain model as "wrapping the database" (description on the ruby on rails front page) and using the database as your starting point is in many cases the wrong way to go. We also couldn't use it on the project I am on because database schema changes are going to be expensive/difficult so we want the domain to vary independently from the database (as far as possible). Ruby on rails still interests me but I think so far I agree with the author of this post about ruby one rails being a different mentality from DDD.

The question of learning Ruby the language is more difficult. It is an attractive language and I like the idea of using it for DSL's but I think the author of this post on whether its worth learning another language is spot on, I'll be better served spending time on TDD/OOP/SOA/DDD instead.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone