So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
Domain-Driven Design
11–20 of 198 posts
Re: Domain-Driven Design
#12> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…
I find it hard to understand how you'd get the essence of the idea from some of these descriptions, I was lucky enough to be at OOPSLA when Erics book came out and he had a session on it, I think he explained it pretty well, not sure if there are online presentations of his that are good, his book is good, but has a lot of extra more "technical" stuff to deal with how to implement it.
Re: Domain-Driven Design
#13> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…
The book that introduced the term, “Domain-Driven Design” by Eric Evans, is thick but excellent.
Re: Domain-Driven Design
#14So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations.
ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.
Re: Domain-Driven Design
#15So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
DDD is sort of the OOP of OOP, without the clever Design Patterns. -- DDD is the kind of principles most OOP people can learn and apply in the same mechanistic way the apply OOP principles and that actually do pay off (unlike design patterns which are really clever but have very little impact in real world).
CQRS is associated with DDD because it is the kind of smart pattern made out of bits that the other smart patterns frown against -- like data duplication/denormalization.
Re: Domain-Driven Design
#16So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
I think the definition of DDD is abstract on purpose.
I proposed a one-liner a couple of years ago [0]:
* The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain *
But to be honest, in hindsight I think it was nothing more than a drip in the ocean, and does not clarify a lot, unless you are already well versed in DDD; it's like those explanations about monads...
As for the CQRS-as-a-top-level architecture:
There are a lot of "beginner experts" and self-proclaimed thought leaders emerging, as DDD is getting more popular... (~= Agile movement)
CQRS-all-the-things is typically a phase that you go through if you are studying DDD. (I've been there, done that, got the T-shirt.)
In my personal opinion a good heuristic to detect "beginner experts" is that they prefer to use a lot of DDD lingo, and focus on the more technical aspects instead of truly trying to understand the business domain first.
Update:
Added the first paragraph with an attempt for a DDD definition.
Re: Domain-Driven Design
#17We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years).
Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD?
In our case, simple CRUD APIs that in "regular programming" might take a couple 200 line files have turned into unmanageable nightmares in DDD that take you at least a couple of days of really intensive investigation to understand, because it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go.
Now, you could make the argument "You Are Doing It Wrong(tm)" but since I'm just a drone in this specific scheme and there's no wiggle room for anything (the team is quite inflexible on this) I have to follow it to the letter.
Just giving my two cents, again, not depreciating DDD, it has its purpose but in my opinion, it's for very specific projects.
Re: Domain-Driven Design
#18I didn't read the PDF but it seems a way to formalize the usual analysis of customer requirements. It goes like this:
1. Understand the business of the customer, or any requirement won't make sense.
2. Learn the jargon of the business, or you won't be able to communicate.
3. Use that jargon when naming database tables, software modules, variables, everything, or you'll have to translate between your possibly abstract names and the jargon of the business.
So, apparently nothing new but I should read the PDF (too bad it's not HTML) because there could be new useful ideas about the process.
Edit: oops, the PDF is only that page as PDF. I'll google for it but does anybody have a good link to a detailed explanation of the method?
Re: Domain-Driven Design
#19So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
It's because a popular book on DDD "Implementing Domain-driven Design" uses CQRS in its examples. If the book was written today CQRS would probably be replaced with Serverless computing or something even more trendy.
Re: Domain-Driven Design
#20We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…
> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go.
When you put engineers in charge you get overengineering and when you put managers you get underengineering.
Is there a way out?