Is DDD Worth It? It Surely Aint Gonna Save Us!
In this post, I will play the devils advocate a bit.
I attended several of the sessions in the Domain Driven Design (DDD) track on Øredev 2008 today, and to the end of the panel debate, I kind of got to thinking: “Why actually bother ourselves with DDD?”
Now, don’t get me wrong here. I actually like the idea of extra emphasis on domain modelling in our profession. Indeed, I wrote “DDD Wanna-Be” as the tagline on my conference pass. I really wanna do DDD. By I also got to thinking: “Why, actually?”
Being the Devils Advocate
It is old knowledge in the computer science industry, that no new tool or language are going to make us orders of magnitude more productive than yesterday. When going from imperative procedural to object-oriented programming, we get to express models in another way, said to be more like the real world. But it really does not make us any more productive than we were in the imperative thinking.
Likewise with DDD. I cannot see it making us orders of magnitude more productive, than when not doing DDD. I really do not. Sure, distilling the core domain seems a good idea, and protecting it with an anti-corruption layer might also be a good idea. And so on. But overall, the development of an application will not go way faster as a consequence of applying DDD. Actually, I think applying DDD to your application development can have the effect of slowing you down. At least while you learn. This is okay, if there is a bonus in the end. But is there?
And do the computing industry actually need saving? It is repeated again and again, how too little focus on domain modelling will create messy, unmaintainable systems. Maybe so. Maybe not. In close co-operation with colleagues and clients I have helped build lots of systems, that both meet the users needs by supporting the business domain while at the same time being maintainable. And we were not practising DDD.
Back to Being Myself Again
So why do I still like the idea of striving for more domain modelling?
Maybe because I find it an interesting academic exercise. Maybe because I see emerging DDD-supporting, interesting technology in stuff like spring load-time-weaving to inject into all of the domain, that I will get to play with then. Maybe because it is something new. Maybe to not be bored by always doing what I did yesterday, even though it worked for me just fine yesterday. Maybe to bring the fun back.
Do you do DDD? And if so, why? Honestly 
November 19, 2008
Tags: DDD, domain Posted in: Design, Programming
7 Responses
You neglect to explain what DDD is or is referring to anywhere in this post for readers who wouldn’t otherwise know. There is no link to any explanation, only a conference that makes the assumption you already know what DDD is.
Fail blog post is fail.
Your writing is inaccessible to so many potential readers..
I consult on many projects and what I usually see is procedural code and a relatively poor correlation between the problems being solved and the code conjured up to solve them. I call this “C” code because it’s very average–I wouldn’t say that it sucks necessarily as I’ve seen several multi-million dollar companies succeed with “C” code. Almost always, this procedural code is written using a programming language that supports object-oriented modeling.
I became a fan of DDD when nice tools made it possible to build applications using unencumbered object-oriented code. Hibernate and Spring are good examples as they allow developers to write Plain Old Java code that doesn’t explicitly deal with persistence, transactions, or the assemblies your objects find themselves in from one application to the next.
This unencumbered domain model is usually where I start most of my projects and since it’s straight-up and simple code it’s easy to test and easy to refactor. I think of the domain model as the “demilitarized zone” of these applications. The rest seems to fall in place once you have a good domain model.
I’ve seen several projects succeed in the face of shifting requirements because they had a domain model–with a good domain model developers are generally not afraid or hesitant to change things as needed. Done properly, the fallout from such changes is mostly contained to the domain model. Furthermore, teams that embrace DDD put a high priority on having an accurate and up-to-date domain model and often seek out and welcome such changes since they help the fidelity of the domain model. That contrasts sharply with other projects I’ve worked on where developers were afraid or hesitant to make such changes.
DDD is 90% common sense and I think the DDD community is self-conscious of this fact. The most common answer folks receive on the DDD mailing list is “it depends” and it’s the correct answer in my opinion. Every domain is different, every application is different, every software development team is different. Focus on understanding those differences and building code that models your domain directly and you’re doing DDD.
That’s it in a nutshell.
.02
hernan
I think you meant to say “procedural programming to object oriented programming” and not “imperative to object oriented programming”, because OOP languages are also imperative.
With that said, DDD is too abstract. In theory it seems like a good idea but the underlining technology must be concrete and not abstract. What you will lose is precision in the implementation and efficiency.
I’ve used domain driven design on projects where I got to design the domain model from scratch and it worked well. I find that the more effort you put into the domain model, the less code you have to write everywhere else. The software also tends to have fewer last minute bugs due to constraints being enforced by the model instead of the business logic and the UI.
I’ve also worked on projects where domain driven design wasn’t used. Constraints were enforced haphazardly if at all. Code to handle special cases proliferated. The business logic was hard to understand or change. The applications produced an unending stream of production bugs which consumed increasing development resources as new feature development slowed to a crawl.
I don’t think domain driven design is really anything new, however. It’s basically just entity relationship modeling for object oriented programmers. It’s nevertheless useful since many programmers aren’t familiar with E-R modeling and don’t see it as applicable to what they do.
Hi,
Maybe you can’t see a productivity improvement in DDD because you already apply it? I agree with hernan above, who said that DDD is 90% common sense. Maybe you are alredy using the real important principles of DDD.
Another possibility is that you build lots of systems, but you didn’t have to maintain those systems in the long run. With a clear Domain Model, it is much easier to understand and apply change.
I had similar thoughts a while ago, and decided to write a small simple domain as an “academic exercise”. I found it hard trying to accomplish a domain-driven design. The code base was heaps bigger than it would be if I hadn’t bothered with immutability and protecting the integrity of the domain. The conclusion:
- Harder to write good code.
- Easier to maintain the code.
- Less errors.
In other words I would probably do it in a large scale project as well.
You can have a look at a demo and download the source here (feedback appreciated):
http://larsen.blogsite.org/blog/?page_id=162
I so wanted to believe that you were referring to the good old Data Display Debugger ( DDD ) —
Leave a Reply