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

DDD Is Overrated

tilkov.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: DDD Is Overrated

#71

Post by hotcrossbunny »

I think it is often more helpful to ask the question "To what extent is XDD useful in context Y?". This firstly shifts the discussion away from whether something is universally good or bad (the space of bandwagon riders and hype curve surfers), and secondly avoids trying to comment on what one believes to be the popular opinion at some particular point in time.

Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.

Re: DDD Is Overrated

#72

Post by fenderbluesjr »

kristopolous wrote: post #69
FieryTransition wrote: post #61

Earlier quoted context omitted.

Agreed, sounds like they are trying to say that two people in different settings can make changes without understanding the reasons. It could also be summed up with, "go talk to each other"

I summarize all those theories as "how to be a human". There's all these tech business books with titles like "Lean Innovation" and they must be written for people without the crudest socialization skills. It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant t…

I encourage you to read more.. Your take on the wikipedia article reads as as you had your decision made up beforehand. The words he uses, which you think are too elaborate, have specific definitions within the context of the book. Your 'summary' missed the mark completely

Re: DDD Is Overrated

#73

Post by NicoJuicy »

stevebmark wrote: post #47
mjgs wrote: post #42

Earlier quoted context omitted.

You make some valid points, but “good ideas written by someone who should not communicate with humans” - a bit harsh don’t you think?

After reading all 500 grueling pages of DDD, that could have been 50 pages, no, I do not regret my hyperbole. I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.

Here you go : https://www.infoq.com/minibooks/domain-driven-design-quickly... ~100pages

Here a smaller one: https://github.com/engma/ddd-inanutshell

Re: DDD Is Overrated

#74

Post by ChicagoDave »

I think this article skips the most important aspect of DDD.

Reducing Complexity.

If you’re building simple systems, you don’t need DDD and Evans has always been clear about that.

But when you have a complex system, using DDD to “pull it apart” is highly effective.

What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools.

DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans.

It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities.

DDD isn’t just about root aggregates and value objects.

It’s a communication tool and a pretty damn good one.

Re: DDD Is Overrated

#75

Post by bopbeepboop »

arwhatever wrote: post #70
bopbeepboop wrote: post #55

Earlier quoted context omitted.

To elaborate — Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”. In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transacti…

Interesting to see all of the discussion on hard-coding vs configuring domain/business logic, when in reality most line-of-business app developers are never introduced to the very concept of business/domain logic, and therefore it gets strewn all throughout an application’s code based, tangled in with data retrieval, u/i concerns, and everything else.

Yes — the goal of DDD is to explain why that’s a bad idea. For two reasons.

1. It makes your code a mess.

2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?

DDD argues you should develop software by:

1. Talking to customers about the domain until you have a shared language with specific terminology.

2. Write that down as a model.

3. Write that model as software.

I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.

DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.

Re: DDD Is Overrated

#76

Post by huseyinkeles »

radicalbyte wrote: post #68
Jach wrote: post #34

"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that b…

You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't…

What is GoF book?

Re: DDD Is Overrated

#77

Post by detaro »

huseyinkeles wrote: post #76
radicalbyte wrote: post #68

Earlier quoted context omitted.

You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't…

What is GoF book?

"Design Patterns: Elements of Reusable Object-Oriented Software". also called the Gang-of-Four or GoF book for the four authors.

Re: DDD Is Overrated

#79

Post by kristopolous »

fenderbluesjr wrote: post #72
kristopolous wrote: post #69

Earlier quoted context omitted.

I summarize all those theories as "how to be a human". There's all these tech business books with titles like "Lean Innovation" and they must be written for people without the crudest socialization skills. It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant t…

I encourage you to read more.. Your take on the wikipedia article reads as as you had your decision made up beforehand. The words he uses, which you think are too elaborate, have specific definitions within the context of the book. Your 'summary' missed the mark completely

Of course they do. That's part of the theater.

Some things are genuinely complicated and others are intentionally so.

This is clearly something that is complicated by choice, not by necessity.

All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.

They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.

I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.

It's a "type", more rare than others, but they're out there.

If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.

Re: DDD Is Overrated

#80

Post by rramadass »

rtpg wrote: post #3

One thing I heard recently, that I found pretty true when role-playing in my mind, is that most of the design methodologies get like... 90% of their value from forcing _a_ methodology onto people. The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship st…

See the paper A Rational Design Process: How and Why to Fake it by David Parnas for the origins of the idea. - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
Post reply on HN