Sergey Shishkin

on agile software development

When To Use Domain-Driven Design: Take Two

To answer the comment to my thoughts on DDD from Stefan Lieser I’d like to state my point clearer:

I never said that data-centric development is preferable over DDD. Data-centric approach can ruin a project if abused. DDD actually brings lots of useful patterns and practices which are also valuable on their own. But each tool has its cost and I won’t blindly dismiss data-centric approach only because I have DDD in my toolbox.

Stefan proposed his DDD way of starting with "yet another web-shop":

If I would have to implement "yet another web-shop/blog/you-name-it" I would start top-down and specs-first. Maybe I would use a front controller and the controller would talk to a service that acts as a facade, shielding the underlying model. All that would be driven by specs. The service would use objects from the business domain (shopping cart, cart item, blog post, author, whatever). Those objects would be relatively simple, maybe in v1 of the application some of them would be data-only without much behaviour. The last step would be to use a mapper to persist the objects to the database. Is that approach DDD? I think yes. Does it have a lot of data-centric classes in the beginning? Maybe yes.

The biggest advantage I see with a clear DDD approach is that you can do it top-down specs-first. WatiN is nice for integration tests, but I don’t want to drive my implementation by WatiN tests.

This is an absolutely valid approach in my eyes. But surely not the cheapest one if we talk about a start up. Remember, our goal is to deliver something having a business value as soon as possible. Do we really need all that controllers, services, models, specifications/tests to start with?

Incremental Development

I’d probably end up with the same DDD-like architecture for the v2, but I prefer to add things as I need them. Yes, I prefer to start with a disposable top-down data-centric solution which I’ll refactor into something DDD-like as/when/if complexity arises.

What I would start with is very well described by Scott Guthrie on his blog: Start with a good static XHTML/CSS boilerplate. Then replace static parts with dynamic controls bound to a Linq Data Model. At this point it should be enough for a Joe’s weblog (interesting to measure percentage of projects with such complexity).

Caution! This pragmatic approach is in fact very dangerous. If you continue to add features without refactoring the architecture, you will suddenly pass the point of no return and your project will be buried under its own accidental complexity.

Introduce Controllers And Query Objects

After I notice repeating myself in data queries, I would abstract them into Query/Specification Objects. The need of unit testing naturally emerges at this point as I can’t keep all the accidental complexity in my head’s RAM anymore and need some kind of backup. So, Controllers will be introduced, as the amount of GUI code increases, to support unit testing.

Now we’re far beyond of what a Joe’s weblog basically needs, and we can even run a small- to mid-sized web-shop. The architecture is almost the same as the Stefan’s DDD approach, except I have my Linq-specific Data Model instead of a POCO Domain Model. That is why I still call this approach data-centric, although I use several DDD concepts.

Summary

If we return to the point of my previous post: POCO Domain Model is there to manage change in complex domains. This is not the case for the above described scenario, and thus I won’t go with POCO Domain Model until I’m proven the opposite.

Advertisements

Written by Sergey Shishkin

14.10.2008 at 01:19

Posted in Uncategorized

%d bloggers like this: