[m110]

Well, this is bascially what DDD proposes. To write code that reflects the domain, so even your manager understands it. But for some reason, when you call it by a name, people start saying you don’t need those dogmatic patterns. That’s my point.

[pdimitar]

Not what I observed. When DDD is mentioned, a lot of people want to abstract the entire Universe just in case.

DDD sadly often goes hand in hand with a ton of enterprise Java-like practices that never ended well for anyone applying them. It's one of the collective delusions that's apparently too persistent to disappear by itself.

Resisting the temptation to abstract everything behind factories / config providers / dependency injectors et. al. is a crucial skill in programming and project management. Most people fall to the temptation however.

[m110]

This is what the article mentions. It’s not about the tactical patterns, but the strategic ones.

DDD is absolutely not about factories or dependency injection. It seems like you mix up Java with OOP design patterns and DDD and treat them all like the same thing. They’re not.

[pdimitar]

Think we're talking past each other a bit. :)

I am not mixing those up. Even when I only had 3-4 years of experience I was very keenly aware they are separate things. But 90% of the people I worked with did mix them up and forced their decisions on me.

I know DDD can be applied sparingly and to produce common-sense code that can be easily read by (almost) anyone and it's what I strive to do for years every working day.

What I was saying is: it's an uphill battle against the mob rule of a lot of people who get easily hyped and lack analytical and critical thinking skills and just blindly apply every single enterprise pattern they've read in a book.

To that end I somewhat agree with the article -- but not completely.