I clicked this article to find out what DDD is as I've heard the term and was curious to learn more about it. Unfortunately, this article does very little to enlighten me besides the very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do.
The above idea is hardly revolutionary anyway, I'm sure many people operated this way DDD or not.
This seems like another one in the endless stream of innovative project management methodologies that promise to make everything better, but whose main purpose is creating lucrative make-work opportunities to the next batch of consultants and evangelists.
very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do.
Much of DDD is common sense, what it offers is a way to be explicitly common sense. The important factors, the way I see it, is to explicitly make sure both developers and stakeholder have a shared mental model of the business process that maps to the domain in question, they all agree on which 'jargon' terms map to which parts of that model AND that that model (with the agreed upon terms) is explicitly represented in the code.
Keeping in close contact with the business domain people is most useful if you actually understand each other. Too often I've seen developers and business people using the same 'every day' word when discussing a problem and only much later do they find out that their obvious understanding of that word was very different.
Nope, still means nothing too me. I'll just accept that how this bucket of words is supposed to form some cohesive methodology or pattern for anything is beyond my understanding. I'm sure some people get paid a lot of $ to implement it tho.
Simple Version. Before writing a function that reports how many of a certain thing has been "sold", make sure everybody involved agrees what "sold" means in this specific context and domain. And once you have agreed, make sure that every time a function, variable or database table talks about things "sold" it's using that definition.
How complex your methodology around this has to be depends entirely on how complex the domain is and how many different definitions of "sold" is used with different parts of that domain.
Ah, ya in our code no one can agree on what sold means so we just trial and error for which one seems to work in each circumstance. Or sometimes we need both so we'll have..
It may seem like common sense, but I have worked with many people who don't understand the importance of the actual software reflecting the domain that is being served. It's funny that DDD is criticized for being "too technical" when the whole point of it is that technical concerns must always serve the domain / customers, and that technology merely enables that.
And, conversely, I have seen many people get extremely excited about solving technical problems that aren't related to the underlying business in any way. That is why the book needed to be written - people are more concerned with the newest database or frontend framework, but have lost sight of the purpose of software: to provide value to people.
So, sure, there are DDD consultants and trainers. They're going to capitalize off of the idea like vultures, as is done with all ideas and movements. But, the core beliefs of DDD seem like a good idea to me.
The above idea is hardly revolutionary anyway, I'm sure many people operated this way DDD or not.
This seems like another one in the endless stream of innovative project management methodologies that promise to make everything better, but whose main purpose is creating lucrative make-work opportunities to the next batch of consultants and evangelists.