Part One
Part Two

In the last instalment we finished up with a suite of passing tests. However, we’ve yet to produce anything remotely usable so lets continue by reaching down further and driving out our services/persistence. We’ll start by writing the following test:

We’ve meddled with our test setup a little to introduce the MockRepository for mocking out our PostController’s new dependency on the IBlogPostService. Our test now calls the AddPost method on our service interface and sets up the resulting AddPostResponseDto. Running the test produces a bunch of compiler whinging so we best implement the newly introduced bits:

These are the only changes and additions we’ve made in order for the tests to compile and run. Running our test now produces the following result:

As we’ve yet to modify the PostController.Save(…) call to include a call the newly introduced IBlogPostService dependency. Lets go ahead and do this now:

We’ve now included the call to our newly introduced service and we set the responseMessage if the response is signaled as successful. Lets run our test now:

It works, ship it! Actually no, again we’re pretty low on actual functionality right now. Remember we’ve yet to actually drive out any implementation of the IBlogPostService interface as yet and I expect that the acceptance test will fail horribly since we didn’t wire up the necessary container configuration either. Lets go ahead and run the whole test suite and see what gives:

In the brief moments the browser appears during the test we can see the following:

Hmm, as I predicted earlier our application fails to run due to the lack of proper container configuration. Before we can do this we need to implement the IBlogPostService interface somewhere. We need to write a failing test to begin our foray into the implementation of a BlogPostService:

Lets create the BlogPostService only performing the steps necessary to pass the test above:

Run the test:

Now we have a working BlogPostService we can now wire up our container configuration to pass the acceptance test:

Now running the full suite of tests produces the following:

Our tests pass!

That’s it for this post. I’ve checked in the latest changes to the repository. In the next post we’ll continue our efforts and begin to implement validation on our screen-bound DTO’s.

Google code hosted project: http://code.google.com/p/mr-blogengine/

An interesting discussion was brought up in one of the ALT.NET groups regarding the use of DTO’s in the presentation layer that I had to chime in on.

I’m a strong advocate of message passing from the UI to your services for several reasons:

1. Test driving from the top-down is my favoured approach when developing web applications. I’ll start by writing a failing test for my controller (you should know by now I use Monorail ). Then I’ll stub out any dependencies, these usually being service interfaces which accept and return simple DTO’s with absolutely no behaviour. Stubbing out the services allows you to return dummy data very early on in your development. The nice thing about this approach is you can get a working UI together very quickly and then drive out the development of each layer until you hit your domain model. From which point you can then wire-up your real service and repository implementations and satisfy your acceptance tests end-to-end. Now I’m not suggesting that this approach isn’t possible without DTO’s but it makes it a heck lot easier in my experience.
2. DDD aggregates by their very nature are composed of behaviours you don’t want to pass into your UI. Using DTO’s for binding into your UI keeps things nice and lightweight. Cohesion is high as the DTO’s are created for a very specific purpose, usually to satisfy a particular screen or UI workflow.
3. I had made the rather nebulous statement that the use of DTO’s insulates your UI against changes in your domain model. Quite rightly somebody replied saying that this was all relative and there are many means to insulate against change. Of course, I wholeheartedly agree but in my defence I was replying to the OP from my iPhone. Now for me to explain this a little… Unless you’re using query projections (a la NHibernate) you’ll be mapping from your domain entities to specific DTO’s using some kind of mapper class. Your mapper probably depends on the interfaces of your particular domain entities and the implementation of your DTO’s. I say implementation as I drive out the mapping using state-based testing, which of course makes perfect sense when mapping from one state to another! Using DTO’s means our controller has a nice seam between itself and the services through their interfaces thus the controller (read: UI) has no knowledge of the domain model at all. Any changes to the domain model are catered for by changing the mapper specific to the affected messages. I won’t get into versioning messages, mainly because I haven’t got the time or inclination
4. I’ve always thought (and I read this somewhere I think, but can’t remember where) that a sign of a well designed architecture, among other things of course, is the ability to replace the UI and have everything function correctly. Now it was probably more poetic than that but essentially what this means is your UI should have absolutely zero dependencies on anything below your service interfaces. Using DTO’s and message passing means the only work your controllers are doing is scraping the request, passing your message to a service and binding the response. I’ve demonstrated this in systems I’ve developed by providing an API (which can be considered another UI if you squint a little and look sideways) which is comprised of exactly the same service calls and DTO’s my web UI is using.
5. My last point isn’t specifically tied to the use of DTO’s but more based around messaging architecture in general… What this gives me from the very beginning (i.e. the first test) is a nice basis for distributing my architecture. Our services can be hosted on an application server separately from our web application  or preferably located transparently via a message bus which brings in a whole heap of nice side-effects…

So in summary you can see I’m a big fan of the domain model in my services, mapping to and from DTO’s in my UI. What is your favoured approach?

My plan is to build a basic blogging engine using Castle Monorail, Windsor, ActiveRecord and developed with DDD & TDD. I’ll screencast the whole procedure from start to finish, outlining the basic story or stories for each screencast episode and then go ahead and implement those stories.

Due to the (potential) size of this I’ll no doubt split this up over many screencasts – probably weighing in at around an hour or so per piece. Production values will be conspicuously low of course and the screencasts are not necessarily meant to serve as an educational tool, more a window into my usage of tools & techniques.

I’ll spike out the solution bootstrapping and structure before the first screencast rather than bore you with the requisite stuff. Anyway, expect the first bunch of stories to appear some point early next week…

Take a look at this talk on DDD given during Spring 2007 by Chris Richardson for a heads-up. Its probably the most concise I’ve seen on the topic so far.

Have a look.