Take the 2-minute tour ×

I heard about Domain Driven Development from a developer in the area. He talked it up like it was just about the silver bullet to changing requirements.

I read the wiki. Still not too clear. What is "3D" in practical terms? Is it really that amazing that now UML class diagramming is just obsolete?

share|improve this question
As far as I can tell, UML was always obsolete. –  DeadMG Feb 5 '12 at 14:53

4 Answers 4

up vote 16 down vote accepted

Well, first of all, I don't think that the Wikipedia article you refer to is very good, mostly because it references a bunch of things that are only ancillary to Domain Driven Design and does little to enlighten anyone about the practice.

But, as someone who has taken Domain Driven Design to heart (which usually goes by DDD, rather than 3D, for what it's worth), I always felt the fundamentals of DDD are obvious, if you read so much as the first chapter of Eric Evans' book. But it is a set of patterns and practices, so it's not that easy to give a 3 sentence summary of what it is and what the advantages are without going into some detail. Which details resonate with any one person might be very different, too; it's probable that 10 years ago I wouldn't have seen the point at all, myself.

DDD is not a silver bullet. When done sensibly, it's about taking a craftsman-like approach to building software, and recognizing the need to reduce the cognitive friction between development teams and the businesses they are building software for. One of the most important practices is to have a layer in which the domain vocabulary used by the software team and the business team matches as closely as possible. You build this layer iteratively as you come to understand the business problem that you are trying to solve. When business logic is sensibly encoded in this layer, isolated from all the convoluted dependencies that enterprise applications typically have by factoring interactions with those systems out to interfaces, the language used in the actual domain layer eventually becomes fairly concise, obvious, and readable. When you review your model with the business, they will often correct you, and you gradually refactor to a deeper understanding of the domain.

Considering the shape that I've seen most enterprise software in, in practice, DDD may sound like a silver bullet, because most enterprise software has such poor separation of concerns that it's nearly untestable, and the software team lives in great fear of change because they have no idea what the side effects of ostensibly even trivial code changes might be, whereas a properly factored domain layer will be independently testable and verifiable. But actually, DDD acknowledges that systems rarely exist in isolation. DDD includes coping patterns for legacy systems (Anti-corruption layer, bounded contexts, to name a couple).

If you practice object-oriented design, including the discipline of loose coupling, and you practice unit testing fairly religiously, and you mercilessly refactor code, and you work with domain experts while building your system, essentially you'll end up with a result that's basically what advocates of domain driven design are talking about.

There are a few specific patterns described in Evans's book that apply mostly to enterprise software development, and some that are fairly universal principles, but essentially, DDD is a pragmatic approach to software development that can, over time, reduce the buildup of technical debt, and make your customers happier because you are able to speak the same language with each other, and deliver better-working solutions because of the advantages of understanding each other better.

share|improve this answer

A high-level description could be -

Model your classes to mirror the data structures and behaviour of your problem domain.

This allows you to map changes in your problem domain directly to changes in your code, so it should be more easy to update as your problem domain evolves.

share|improve this answer

I agree that class diagram with MDD is obsolete. It doesn't mean that UML but only Model Driven Development is over for me.

share|improve this answer
What does this have to do with Domain-Driven Design? –  Otavio Macedo Dec 4 '11 at 20:59
Model Driven Development using templates to generate code like a hen to pound an egg is obsolete. Agile modeling in which UML class diagram is only a graphical viewer of the code is appropriate. For requirements and other needs we can still use other diagrams or high level class diagrams. –  UML_GURU Dec 5 '11 at 9:36
You mean tools like the class diagram generator in visual studio are preferred? –  P.Brian.Mackey Dec 5 '11 at 14:20
It is a good start but not enough. I simply mean that class diagram should be agile and be free to model at UML level, but also code and make decision at code level but always be able to keep model and code in synchronization. I simple mean flexibility and multiple iterations at code and model level. –  UML_GURU Dec 5 '11 at 14:48
MDD (Model Driven Development) has always used UML but MDD is not UML this is templates which help to generate code from a model which is usually a graphical UML class diagram. Once the code is generated then the modeling phase is finish with MDD. I disagree and UML should be used during all project life this is why MDD is useless while UML is the golden graal. –  UML_GURU Dec 5 '11 at 14:55

I realise this question is a couple of months old, but I thought I'd share my brief experience of DDD.

I helped write a pretty standard 3-tier Java web application last year on a project that implemented DDD via code generation. DDD for us meant maintaining a package of heavily annotated domain classes, and then running a code generator (inherited from a senior developer) that would generate huge swathes of our code (persistent classes, DAOs, web service classes, some UI code).

The pros/cons I drew out of this way of working are largely the arguments for/against code generation.

share|improve this answer

Your Answer


