Is DDD a waste of time?

Many developers who think DDD is useful for their project fall into the trap that they think what their job is all about is writing code. This isn't the case. A developer's job is about realizing functionality so a problem can be solved through software. This results in the conclusion that writing code isn't the beginning of what a developer is doing, but the end: the code is the result of the whole process BEFORE the code is actually written.

DDD isn't about writing code, it's not a turn-key 10-step process to get great software, it's about that whole process BEFORE the code is written, it's about getting insight in what the problem is all about, what/who participates in which information streams and what do these elements look like, how do they relate to eachother etc. etc. In fact, the most important part of DDD is creating a language which makes conversations between domain experts and developers possible without misinterpretations. This is the 'Ubiquitous Language' Evans talks about. It in effect makes the whole process BEFORE the code is written a process which leaves little to be guessed, things are clear and straight forward. (that's the goal).

The problem with 'how does DDD work in practise' and 'could anyone give me an example of how I write code with DDD?' and the like is really coming from the fact that the people asking these kind of questions focus on writing code, but have no idea WHY they're writing THAT code and not other code. I.o.w.: if you realize that DDD is about discovering WHAT you've to write as functionality and WHY, things fall into place. HOW you're writing that code, that's up to you. But as said: that's not the biggest problem anymore, as you by then already know what you've to write and why.

Here is a very similar question: Do you allow the Web Tier to access the DAL directly?

I use DDD for all my projects. On the smaller applications some of the concepts don't apply, but I find many of the aspects are applicable on all projects regardless of size.

you know, sometimes the 5% makes more money than all the other 95% - that's why DDD exists.

it's for specific complex large system.

DDD is about software that will be maintained for a while. To me this means that it needs to express ideas that will change with the domain. Sure a simple app may be perfect for a short delivery time and short implementation time. However if you need to grow the software then DDD principles will help immensely. DDD may be hard up front but once you get the idea of the ubiquitous language and the separation concerns then things do start to become easy.

If you read the article a little more, you see this:

For the 5% of applications where DDD is a good fit, it is a very good fit. For those situations, DDD will help you crack a very tough nut. Here, DDD may be the silver bullet for that werewolf that your manager just pointed to your desk.

That's why the fuss about it.