Is DDD a waste of time? [closed]

Solution 1:

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.

Solution 2:

Sorry but if DDD were only a way of thinking as Frans Bouma says, then it would not recommend such things as Persistence Ignorance. This is dismissing others as somewhat underclass developers.

PI, for which DDD has at least a bias, is an architectural choice. It is not a way of thinking anymore ; it is already something being served to you, with most of the time too vague warnings to be of any use: "not suited for everything".

But deciding to go the PI way or not is a challenge in itself, and you can't call names someone ("a coder") if he feels uneasy about this.

Take an ERP package with all-over the place a MS Access-like interface: grids with running totals, auto-updating columns and pageless scrolling on a 100 000 records. Clearly a DDD approach is suited for thinking of how to go about this app. But in years I have never seen anyone - neither in books nor online, going though evidence backed explanations, let alone real life code examples, of how PI could deal with this ubiquitous situation for anyone wanting to deliver commercial grade apps and user experiences.

Don't want to get religious on this. DDD and DAL proponents tend to be overly religious and may drive away those who have been bitten once but who are/were open-minded. Many just want to confront real-life experiences (i.e. THINK), and not get served with just Cats, Cars, and basic Order/OrdersItems (i.e. poor CODE) to support the preaching.