Archive for October 2008
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?
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.
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.
Tired of "myButton_Click(object sender, EventArgs e)", you can change it to be "OnMyButtonClick(object sender, EventArgs e)". Make Visual Studio conform to the de-facto .NET naming conventions!
Vote for the suggestion on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=374601
Recently on the .NET user group in Cologne Sebastian Jancke made an introduction into Domain-Driven Design. One aspect of DDD remained untouched in the presentation — when should one actually go for DDD and when it is considered an overkill. So, I raised that question (quite provoking actually) and it quickly turned out into an interesting discussion.
My point in the discussion was that DDD comes with its price (relatively high, actually) and you should not use it until you see clear return on that investment. Some people in the audience, however, remained thinking that DDD is an always-win-way (if not even a "silver bullet"), arguing that other approaches cost no lesser.
Well let’s try to analyze what problems DDD is aimed to solve and thus where it is applicable.
What is DDD, by the way?
The key concept of DDD is the Domain Model. Yet nothing new here, domain models in one or another form are present in every software. What actually DDD brings to the table, is the requirement to express the Domain Model in OO classes and keeping these classes clean of any infrastructure concerns (POCO/POJO). That’s it. And everything else told and written about DDD is just about how to actually make it happen!
Why is clean OO Domain Model so important? Each software development practice is aimed to effectively manage change. By keeping domain and infrastructure unaware of each other, DDD effectively allows independent change of each them. See the Onion Architecture for more on this topic.
Another reason for clean Domain Model is to split away essential and accidental complexity. While expressing the essence of the business in a pure Domain Model, DDD hides accidental complexity that infrastructure always brings.
So, when should I use DDD?
Now, when we understand reasoning behind DDD, we can adequate evaluate its usefulness for different sorts of projects. DDD makes sense for developing software of extremely high essential complexity (with a lot of correlated business rules). And/or software with clear future, where the Domain Model can outlast the infrastructure, or where the business requirements change fast. In other cases DDD may bring more accidental complexity than solve.
If you build yet another web-shop/blog/you-name-it (no complexity whatsoever, business doesn’t ever change), DDD is not for you. You probably will benefit from going data-centric way. Linq your data direct to the GUI. You will probably have to do much more WatiN-testing than unit testing, but the site will get up and running with this approach pretty quick compared to DDD.
When building the first version of a product, you want to get to market as soon as possible. Yet the future of the product is totally unclear. Designing the first version for change may not always be a clever decision — market may change faster and you’re out of it before you finish the product. In this case consider complexity of the business domain before going into DDD. If domain is not very complex, you won’t benefit from DDD here.
Once more, in my opinion, DDD makes most sense for building complex software where the need for change is determined. DDD, as any other approach, has its cost expressed in accidental complexity it brings, you should count on that.