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

61–70 of 97 posts

Re: DDD Is Overrated

#61

Post by FieryTransition »

kristopolous wrote: post #48
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

I was literally introduced to that term with this article while I've been using ddd off and on for 20 years Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality. Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a glob…

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"

Re: DDD Is Overrated

#62

Post by mjgs »

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.

At least it was hyperbole, thanks fir the clarification.

Re: DDD Is Overrated

#63

Post by namelosw »

valenterry wrote: post #57
namelosw wrote: post #44

My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned: 1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture 2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your syste…

> 1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream or Flux , unless you are using advanced languages like Scala and can parametrize them as TMonad I'm a Scala dev and I know monads, but what exactly is TMonad ? Like `[T: Monad](users: T[Users])`? > 2. Although it claims to help you to build pure models, the platform yo…

> I'm a Scala dev and I know monads, but what exactly is TMonad? Like `[T: Monad](users: T[Users])`?

Pretty much like it. There's a popular pattern called Tagless Final which lets you parametrize it and then swap the implementation in the last step.

In this way the model layer wouldn't know the underlying implementation is Future, Promise, or Flux. Sometimes it's useful because the developer finds it's painful to migrate from libraries to libraries.

Re: DDD Is Overrated

#64

Post by metanonsense »

Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level.

When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.

At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".

Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.

Re: DDD Is Overrated

#65

Post by playing_colours »

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…

Thanks for sharing the article! The idea of making a framework for executing business logic that can be dynamically defined by users is old. It is realised in rule engines, embedded scripting, DSLs.

As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.

Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.

Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.

Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.

Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.

Re: DDD Is Overrated

#66

Post by zn44 »

This is a perfect hn, reddit blog post. Controversial title catching points even if people don't read it. Simple contents that are easy to disagree with and broad topic that has a lot of meta. Karma production machine

Re: DDD Is Overrated

#67

Post by einpoklum »

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 unexpected ways - so that working on just one side first is not the right thing to do.

Re: DDD Is Overrated

#68

Post by radicalbyte »

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

Re: DDD Is Overrated

#69

Post by kristopolous »

FieryTransition wrote: post #61
kristopolous wrote: post #48

Earlier quoted context omitted.

I was literally introduced to that term with this article while I've been using ddd off and on for 20 years Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality. Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a glob…

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 things"

I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"

Re: DDD Is Overrated

#70

Post by arwhatever »

bopbeepboop wrote: post #55
xupybd wrote: post #38

Earlier quoted context omitted.

That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What you do need is the domain to specify the flexibility of your design. Almost all business need an accounting system. An accounting system can be built following domain driven development. But for it to be useful to many businesses it must be flexible. So the rul…

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.
Post reply on HN