Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Domain Driven Design?

yehohanan7.medium.com

Post reply on HN
Print view View original

121–130 of 175 posts

Re: Why Domain Driven Design?

#121

Post by juancn »

Be careful with Domain Driven Design in high/performance or data intensive domains. It just doesn't produce scalable designs.

Focus on Data Oriented Design instead, particularly on those scenarios, I think this summarizes the idea fairly well:

https://media.handmade-seattle.com/practical-data-oriented-d...

We had and in-office fad of DDD pre-pandemic, it produced some awfully performing designs, mainly due to data copying or translation to the domain objects.

They look fairly pretty and are relatively easy to modify and understand but it's a pain in the ass to make them run fast if the cardinality of the domain objects is really high.

Re: Why Domain Driven Design?

#122

Post by augustohp »

mostertoaster wrote: post #113
stevebmark wrote: post #111

Domain Driven Design is a poison. The book is one of the most poorly written technical books out there. There are a handful of good ideas buried in the 1,000 page unedited verbose rambling slog. The whole book should only have been 10 pages. Besides Eric Evan’s inability to write, the poison of DDD comes from locking in businesses/domain concepts into your core technology, making them inflexible and making it difficu…

The issue with DDD is not in the philosophical concept. In that he is spot on. Things are in hierarchies, everything is described by a combination of two or more patterns that are more fundamental than those below. The problem is always in people thinking it is an easy magic solution. DDD is not easy. If it were it wouldn’t do anything. It is in fact very challenging to come up with an ubiquitous language, and to hav…

I'd like to complement that. Defining/Discovering the vocabulary for the Ubiquitous Language along with Bounded Contexts (Strategic Design) is where most benefits come from. And is, as said and I agree, the most difficult part - there are no recipes, shortcuts or tools to do that for you.

It doesn't help that there is a bunch of frameworks, libraries, articles with "DDD" on their name, mindlessly gluing together patterns and segregating them into layers (Building Blocks). What I see happening the most is people using them and complaining. Which they should.

Of the two parts that compose DDD, "Strategic Design" and "Building Blocks", only one is essential: Strategic Design. But people usually just talk about the "Building Blocks" (a.k.a Anemic Models), as it seems to be the case of "stevebmark" comment. I agree with him that just having Anemic Models, following blindly the Building Blocks part of DDD as rule, is bad. I just think that calling it DDD is a mistake. DDD is the Strategic Design, you don't even need the code for it to work or produce value.

Re: Why Domain Driven Design?

#123

Post by pm90 »

discreteevent wrote: post #108
BulgarianIdiot wrote: post #37

Earlier quoted context omitted.

You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never…

> unless physical boundaries stop you from failing It is also possible to just police it. Supervise it. This is partly anathema now with agile etc. But the iPhone is what it is because there were a few dictators at the top saying "no". This is actually more effective than a physical boundary because: 1) People will hack around the physical boundary anyway. 2) It forces a conversation between the supervisor and the de…

> It is also possible to just police it. Supervise it. This is partly anathema now with agile etc. But the iPhone is what it is because there were a few dictators at the top saying "no".

But then your project design is now dependent on org hierarchy, and getting the right kind of "people". This isn't guaranteed or easy to do, so I would not consider it a serious situation.

Re: Why Domain Driven Design?

#124

Post by jen20 »

stevebmark wrote: post #111

Domain Driven Design is a poison. The book is one of the most poorly written technical books out there. There are a handful of good ideas buried in the 1,000 page unedited verbose rambling slog. The whole book should only have been 10 pages. Besides Eric Evan’s inability to write, the poison of DDD comes from locking in businesses/domain concepts into your core technology, making them inflexible and making it difficu…

> The book is one of the most poorly written technical books out there.

This explains the disconnect: it’s not a technical book. The part about patterns is garbage, as is anything which espouses object oriented Java circa 2004 (looking at you, Uncle Bob and Martin Fowler).

As a business book, parts 1 and 3 stand up rather well almost 20 years later. The patterns part (2) wasn’t even good advice when it was written, though.

Re: Why Domain Driven Design?

#125

Post by jen20 »

juancn wrote: post #121

Be careful with Domain Driven Design in high/performance or data intensive domains. It just doesn't produce scalable designs. Focus on Data Oriented Design instead, particularly on those scenarios, I think this summarizes the idea fairly well: https://media.handmade-seattle.com/practical-data-oriented-d... We had and in-office fad of DDD pre-pandemic, it produced some awfully performing designs, mainly due to data co…

> Be careful with Domain Driven Design in high/performance or data intensive domains.

This is simply untrue. I’ve used domain driven design in trading systems and trade matching engines which have worked at millions of messages a second without issue. This is actually the sweet spot for DDD, provided you read it as business advice and not technical patterns.

Re: Why Domain Driven Design?

#126

Post by blowski »

pydry wrote: post #118
blowski wrote: post #81

Earlier quoted context omitted.

> DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why. The whole point of DDD is that there can't be a one-size-fits-all answer to these questions. Instead, they give you some questions you need to think about, and tools that might help you find answers.

The whole point appears to be that there IS a one size fits all set of design patterns once you've got the right "bounded contexts" and the right "ubiquitous language". It doesn't have anything interesting to say about either one of those things though. The whole idea appears to be a set up for a bunch of design patterns.

There is definitely a part of the DDD community that wants to do it that way. I call it “domain driven design driven design”. But the big names in DDD have all explicitly said that’s wrong.

Re: Why Domain Driven Design?

#127

Post by [deleted] »

pm90 wrote: post #123
discreteevent wrote: post #108

Earlier quoted context omitted.

> unless physical boundaries stop you from failing It is also possible to just police it. Supervise it. This is partly anathema now with agile etc. But the iPhone is what it is because there were a few dictators at the top saying "no". This is actually more effective than a physical boundary because: 1) People will hack around the physical boundary anyway. 2) It forces a conversation between the supervisor and the de…

> It is also possible to just police it. Supervise it. This is partly anathema now with agile etc. But the iPhone is what it is because there were a few dictators at the top saying "no". But then your project design is now dependent on org hierarchy, and getting the right kind of "people". This isn't guaranteed or easy to do, so I would not consider it a serious situation.

[deleted]

Re: Why Domain Driven Design?

#128

Post by cratermoon »

jen20 wrote: post #124
stevebmark wrote: post #111

Domain Driven Design is a poison. The book is one of the most poorly written technical books out there. There are a handful of good ideas buried in the 1,000 page unedited verbose rambling slog. The whole book should only have been 10 pages. Besides Eric Evan’s inability to write, the poison of DDD comes from locking in businesses/domain concepts into your core technology, making them inflexible and making it difficu…

> The book is one of the most poorly written technical books out there. This explains the disconnect: it’s not a technical book. The part about patterns is garbage, as is anything which espouses object oriented Java circa 2004 (looking at you, Uncle Bob and Martin Fowler). As a business book, parts 1 and 3 stand up rather well almost 20 years later. The patterns part (2) wasn’t even good advice when it was written, t…

One of these days perhaps I'll write a meta-pattern on how the software development industry goes through cycles. Every 10 years or so we discard techniques that only gave a 1-2% improvement instead of solving all the problems. We get distracted by a new thing will fix all that. We can't just add to our toolbox, though. First we have to have the ritual sacrifice of blaming all the failures of the previous 10 years on the old techniques, because they didn't solve all the problems.

Oh wait, it's already been written, by Fred Brooks no less. It's called No Silver Bullet.

Re: Why Domain Driven Design?

#129

Post by theptip »

BulgarianIdiot wrote: post #5

I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…

Indeed, Uber re-discovered Bounded Contexts not that long ago:

https://www.uber.com/blog/microservice-architecture/

(Though only after they felt the pain of thousands of disorganized services.)

Re: Why Domain Driven Design?

#130

Post by vans554 »

DDD is just microservices without head of line blocking not sure why everyone hates it. Instead of having 5 microservices you just build an umbrella app exposing the same 5 API. Calls into the umbrella are now at microsecond speed vs 10s of milliseconds in most (run of the mill publicly available) clouds.
Post reply on HN