Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

3 Answers 3

up vote 20 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 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


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.