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

111–120 of 175 posts

Re: Why Domain Driven Design?

#111

Post by stevebmark »

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 difficult for the business to iterate on new ideas. This is a very good article on why you don’t need it (and the author’s example is healthcare, which has complex business domains). https://dev.to/cheetah100/domain-driven-disaster-147i

Something snapped in Evans’s mind around his over focus of Java and UML that made him try to force every idea into a class hierarchy, and force that model onto software development as a whole in the form of DDD.

Re: Why Domain Driven Design?

#112

Post by mostertoaster »

I really liked the reference to platonism at the beginning.

I feel like at times our problems in the west can be rooted in relying to much in Aristotle and empiricism and not enough on platonic thinking (you could swing too far one way though).

DDD’s ubiquitous language IS the key as he says. Political discourse is the king of lacking ubiquitous language, though that seems more intentional, so we can use words intentionally meaning different things to one group or another. The result though is an inability to work out problems. Engineering organizations at least are not intentionally using different language, but the result is the same, an inability to solve problems.

Re: Why Domain Driven Design?

#113

Post by mostertoaster »

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 have it evolve as our own understanding evolves.

Organizations looking to use it to make things easier, are doomed to fail. What it can help with is making things good and right and even beautiful in how a problem is solved.

Re: Why Domain Driven Design?

#114

Post by revskill »

avereveard wrote: post #107
revskill wrote: post #2

I teach programming and software design, too. But i never use domain, driven, design,... as vocabulary. I use function all the time. "Hey guys, just use function, that's all you know to make usable software." What's the problem with NOT following "weird, confusing" patterns and vocabularies. And the result is, all of my students actually make useful code, simple code. Also, most of software recruiters will tell you:…

> Hey guys, just use function, that's all you know to make usable software "Those who can, do, those who can't, teach" comes to mind

"Those who can make shit, do. Those who can't make shit, teach"

Re: Why Domain Driven Design?

#115

Post by ChicagoDave »

revskill wrote: post #100
ChicagoDave wrote: post #9

Earlier quoted context omitted.

This is impractical in real world applications. Breaking complexity is much more than writing better code. DDD starts with listening to the subject matter experts (the business) and agreeing on language and models. You can write a hundred functions that look good, but if it isn’t aligned with how the business thinks, you will have built spaghetti code.

You surely don't know if there exists a practical real world application which only uses function. (Because you don't have access to codebase of all real world applications). That's why your statement is logically wrong. I have no more word to say here.

I never said that. I said you can’t _only_ write functions. If you model properly, you absolutely can have a purely function based system. But if you skip the modeling and listening step, you will 99% end up with junk.

Re: Why Domain Driven Design?

#116

Post by anon7725 »

BulgarianIdiot wrote: post #42
est wrote: post #14

Earlier quoted context omitted.

> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. This is why, BTW, I'm so dismayed Elon Must fired 85% of Twitter. Now many of their critical services have teams of zero or one developer. Those are basically dead services walking.

> Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves.

The organization is often not reflective of what’s actually being achieved. Instead of Catalog, Offer, Order and Shipment you have Alice’s org, Bob’s org and Charlie’s org. If you encode the interfaces between these (impermanent) group boundaries rather than the conceptual boundaries you enter a world of pain.

Charlie might own Order and Shipment because Charlie is the warehouse exec and 20 years ago, when only physical items were sold, all of the order-processing computers were located in a cage in the warehouse. Fast forward to today and the cage is gone, and the order processing system handles digital items and services in addition to physical goods. But good old Charlie still owns the Order and Shipment system because they were baked together 20 years ago.

Re: Why Domain Driven Design?

#117

Post by revskill »

ChicagoDave wrote: post #115
revskill wrote: post #100

Earlier quoted context omitted.

You surely don't know if there exists a practical real world application which only uses function. (Because you don't have access to codebase of all real world applications). That's why your statement is logically wrong. I have no more word to say here.

I never said that. I said you can’t _only_ write functions. If you model properly, you absolutely can have a purely function based system. But if you skip the modeling and listening step, you will 99% end up with junk.

Hehe, actually, i intentionally use the "useful software", instead of perfect, good design, scalable,... software. If you skip that details, all furthur logic will be in wrong context.

Re: Why Domain Driven Design?

#118

Post by pydry »

blowski wrote: post #81
pydry wrote: post #69

Earlier quoted context omitted.

That software and organizations have boundaries and that they matter is true but is too obvious to be interesting. DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why. There is a shared semantic model both inside a boundary and outside. However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language. DDD do…

> 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.

Re: Why Domain Driven Design?

#119

Post by mattgreenrocks »

camgunz wrote: post #68
mattgreenrocks wrote: post #62

Earlier quoted context omitted.

Frameworks are not architectures, and architectures are not frameworks. DDD is an approach to building an architecture that emphasizes domain modeling. Done properly, all the web gunk (and there’s a lot of it) can be mostly isolated from the actual interesting part: the domain being modeled. Until we as a profession understand how to structure code and how it is different from simply choosing Django vs flask, these d…

> Frameworks are not architectures I'm not saying they are; I'm saying you should outsource the building of a framework that implements your architecture of choice when you can. I would also go further and say that if you can't, you should pick a different architecture where you can.

I hear you. I just don’t trust frameworks to actually sell you on an architecture that benefits you more than them. Thus you don’t get full benefits of said architecture because you’re using a sanitized version.

Re: Why Domain Driven Design?

#120

Post by edejong »

BulgarianIdiot wrote: post #39
marginalia_nu wrote: post #13

Earlier quoted context omitted.

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to…

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as…

You might become interested in actor systems.
Post reply on HN