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

81–90 of 97 posts

Re: DDD Is Overrated

#81

Post by franciscop »

einpoklum wrote: post #67
franciscop wrote: post #18

On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.

> definitely underrated Good documentation is under-rated; not sure about designing via the documentation. > excellent way to end up with a very nice API. My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unex…

Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat".

The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.

Examples of libraries I've written mostly this way:

- https://github.com/franciscop/brownies

- https://github.com/franciscop/files

- https://github.com/franciscop/backblaze

Re: DDD Is Overrated

#82

Post by mathiasverraes »

stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what…

> The biggest flaw of DDD I've run into is there's no emphasis on when not to use it

Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.

Re: DDD Is Overrated

#83

Post by mathiasverraes »

These articles are pretty much impossible to disagree with, because they follow the same pattern.

Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.

§1 Clickbait title

§2 Tool X is popular. I'm a fan. Tool X is useful.

§3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.

§4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.

§5 Conclusion: Not all things require Tool X.

(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.

It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.

Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)

Re: DDD Is Overrated

#84

Post by FieryTransition »

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

I think the problem is that these methods and authors are heavily incentivized to make a name for themselves and a framework which can become a business somehow.

There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.

If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.

Re: DDD Is Overrated

#85

Post by twirlock »

People talk about DDD and mean two mutually exclusive things depending on the scenario. It's either an excuse to have domain concepts pervade your whole stack or it's a description of clearly labeling your models. The prior seems like a naive, bad idea, especially when used with traditional OOP.

Re: DDD Is Overrated

#86

Post by kthejoker2 »

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.

This is literally why Fowler and Evans wrote their books, some of this "tangling" was viewed as a feature because it let a single dev own an issue and avoided the bottleneck of architecture by committee.

Re: DDD Is Overrated

#87

Post by linsomniac »

cozzyd wrote: post #11
HighlandSpring wrote: post #7

Earlier quoted context omitted.

Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned

"man ddd" would disagree speaking of which, ddd is the only application I have installed that relies on motif...

Wow, Motif. Speaking of overrated... I had mostly blocked it out of my head.

Re: DDD Is Overrated

#89

Post by bg4 »

stepbeek wrote: post #35
stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what…

I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.

I found his Effective Aggregate Design pdfs very helpful https://www.dddcommunity.org/library/vernon_2011/, in addition to the DDD quickly book on Infoq, and Functional and Reactive Domain Modeling by Debasish Ghosh https://www.manning.com/books/functional-and-reactive-domain...
Post reply on HN