Domain Driven Design is one of the most complex things a software developer can learn. It's basically a formal ruleset for communication and software development design, based upon a non-existent language, inventing words for fun, and redefining the meaning of other words and sentences - All in an attempt at pleasing the ego of some senior developer such that he can shine in front of others who don't know the "lingo".
DDD is the result you get when you put 500 high functioning Aspies into the same room, all of whom are chemically cleansed of communication skills and social skills, and asks them to reinvent the rules for communication
I once had a colleague of mine who almost quit his job because of his senior manager telling him "you're not following the rules of DDD in your class hierarchies". I wish it was me he had complained about, at which point I'd answer ...
Sorry, I don't have time for DDD, I am too busy creating WORKING SOFTWARE!
DDD is basically the modern priesthood's means to communicate with each other, such that they should easily recognise each other, and become capable of nodding at each others, almost the same way monks and priests have a "new speak language" to facilitate for communication, making them feel "special" being a part of a "secret society of enlightened beings". However, like all superstition it's mostly rubbish from A to Z.
Misunderstand me correctly, there are a couple of nice ideas in DDD, such as bounded context, allowing you to declare a vocabulary, ensuring people are speaking about the same thing as they are discussing software development problems. However, for the most parts it's mostly rubbish new speak, and you're better off simply leaving it alone.
I once had a colleague that spent 10 years of his life learning DDD. Seriously, if you need 10 years to teach yourself how to talk about software, and implement software, maybe you should rethink your software development tools? Just sayin' ...
If you want to have software development tools where applying DDD is not even possible in theory, to completely eliminate the debate, feel free to play around with our Low-Code software development platform. Link below ^_^
Sorry Sir, we can't do DDD because our software development platform doesn't allow us to implement it ^_^
That'll typically "end the debate" about DDD ... ;)
Top comments (2)
When looking at a new paradigm, do you have a method for evaluating if it is useful and what parts of it are superfluous?
A very good question, and my answer to that is; "Does it make my job easier?"
If the answer is yes, it's a good thing, at least within the space from where I'm looking at it. This is one of the things we're struggling with at Aista, implying people look at our stuff and ask themselves if it can do everything their existing platform(s) and language(es) can do, at which point the answer obviously is no. However, its purpose is not to solve everything, its purpose is to make parts of our jobs easier, which it delivers by among other things allowing people to extremely rapidly create backend administration types of apps, from where they can control what their database contains, in addition to that it easily allows for rapidly creating micro services and micro "apps" (if that's a word?) taking control over and simplifying some parts of their jobs.
No paradigm, platform or language solves everything, even though JavaScript made a run for it with NodeJS (and painfully failed may I add). What we need is for the great ideas to "bubble up" naturally by themselves, without religious zealots having fallen in love with some particular tech stack, because they've spent years learning it, and it's provided a stable and secure income for them for some specific domain within software development. The latter unfortunately is the status quo, which makes it very hard and difficult to ensure that the best ideas "wins" ...