WTF is domain driven design

It's when you buy a domain because the name is cool, then think about what to actually put on it.

@Fast-Nop I do the exact opposite of that, I build a thing and then spend 3 days trying to name it

It's when the business dictates what you do with the software rather then the devs build software to do what the business needs.

https://en.wikipedia.org/wiki/...

It's when you stop mixing everything up with a fork in a lasagna.

Bechamel
Minced meat
Bit of nutmeg
Lasagna platter
- repeat -

To protect the inside, finish off with a thick layer of cheese.

If the layers mingle, you did it wrong.

Sounds like bullshit words of management trying to describe wtf the devs are actually doing.

Yet more marketing bullshit meaningless buzz words, watch a total prick near you say it in the next few days then tell him to go fuck himself.

DDD spits into two parts: strategic and tactical DDD. The first is about the organization behind the app as a whole: the domain specific vocabulary and the different contexts that exists and must be catered for.

Ex: a post within devrant is not just a post: it can be a "rant", "question" or something "random". And a post within twitter is called a "tweet".

The second is about different design patterns on how to actual model a domain in code: value objects (inspired by FP) instead of primitive obsession, models as the only mutable objects, loosely coupled and very easy testable via domain events. And there is a lot more (root-models, services, repositories, events, etc.).

Basically there is library code which is very technical, and then there is your own code on top of it with an API that could be understood by everyone working with the app (devs, business, clients). Think DSL in a general purpose programming language.

Fun fact: the only reason DDD is not forgotten is due to its concept of the "bounded context" which became relevant again due to this new thing called "microservices" a couple of years back.