There are two recurring claims associated with DDD: 1) It is most recommended for developing systems with more complex domains and; 2) It must start by spelling out the ubiquitous language of the domain.

By all means, a CRUD system does not need DDD! Any attempt to adopt DDD practices and standards in CRUD systems leads to unnecessary complexities (essential to remember that complexity means cost.) Luckily, [tweet]most systems are made as CRUD by developer choice rather than domain characteristics.[/tweet]

We argue that the ubiquitous domain language should help spell out the motivations for entity state changes. So it seems natural that domain language comes naturally in the design and prototyping of user experience to change these states.

“We threw a stone at the window, and it broke.” Who broke? The stone or the window?

It is a fact that the English language (or Portuguese, as I am a Portuguese speaker), leads us to constructions of sentences that are inevitably ambiguous. For both the writer and the reader.

The effort to construct purely textual descriptions is almost always inefficient. Most of the time, for sheer lack of writing skills. Other times, by the insufficiency of our language.

Starting a system by prototyping user experience (interfaces and usability) is an efficient way to get technical people and business people interacting with media that they both understand. Every new prototyped screen turns out to be at least one entity method or service.

Prototyping is also a cheap way to avoid mistakes. Aldo, it helps users “see” the need for features they haven’t considered. It also allows developers to eliminate features that seemed useful but didn’t arouse expected reactions.

Finally, [tweet]if you can’t imagine a user experience better than a CRUD, then you also don’t have to spend time trying to adapt DDD to your solution. The complexity would be hard to justify.[/tweet]