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

Domain-Driven Design

verraes.net

Post reply on HN
Print view View original

31–40 of 198 posts

Re: Domain-Driven Design

#31

Post by torginus »

I clicked this article to find out what DDD is as I've heard the term and was curious to learn more about it. Unfortunately, this article does very little to enlighten me besides the very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do.

The above idea is hardly revolutionary anyway, I'm sure many people operated this way DDD or not.

This seems like another one in the endless stream of innovative project management methodologies that promise to make everything better, but whose main purpose is creating lucrative make-work opportunities to the next batch of consultants and evangelists.

Re: Domain-Driven Design

#32

Post by AndrewSChapman »

oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

DDD doesn't prescribe any structure really, other than saying you should separate out different contexts and use unified terminology throughout the business, which I don't think anyone would argue against.

Are you talking about design patterns by any chance? Maybe things like repositories, adapters, small and focused service classes and the like?

Re: Domain-Driven Design

#33

Post by tragomaskhalos »

macando wrote: post #20
oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.

Re: Domain-Driven Design

#34

Post by HelloNurse »

oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

In a typical pattern of buzzword adoption, your horrible architecture isn't DDD just because someone calls it so; it's just bad design.

In particular, pulverized source files and excessive abstraction layers are characteristic symptoms of dogmatic, value-oblivious impractical design: quite the opposite of thinking hard about a meaningful domain model in order to use it as a shared language.

Re: Domain-Driven Design

#35

Post by dagw »

athrun wrote: post #10
seanwilson wrote: post #7

> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…

I recently came across this talk from Scott Wlaschin titled "Domain Modeling Made Functional". I found it a great practical introduction to DDD. https://www.youtube.com/watch?v=PLFl95c-IiU

If that talk speaks to you (as it where) I can also highly recommend his book with the same title, https://pragprog.com/titles/swdddf/domain-modeling-made-func...

They are the probably the best concrete and actionable introductions to DDD out there, and do a very good job of separating practical DDD from the OOP dogma that it is sometimes tied to. The book uses F# as it's language to implement and demonstrate its examples, but most of the concepts are presented in a language agnostic way.

Re: Domain-Driven Design

#36

Post by y4mi »

ToJans wrote: post #23
oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

Tactical/technical DDD patterns should only be used for parts of the code where there is a lot of business agility required, so the behavior of your code changes a lot, and you have a tight feedback loop with your business unit. Your story sounds like they implemented a "technical DDD top-level architecture" (TM), whatever that may be. (I'd assume layers of abstractions coupled with logic spread all over the place, w…

> In reality the tactical/technical DDD patterns should only be applied in the core part of your business [...]

I cannot imagine anything where it would make sense unless you're implementing an actual framework such as Spring in javaland.

And at that point I'd say you're wasting effort and just using spring boot should be preferable.

It does make sense with these super low level frameworks though, but which corporation makes them in-house at this point?

Re: Domain-Driven Design

#38

Post by mhd »

dm3 wrote: post #14
tinco wrote: post #11

So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?

Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations. ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.

I've seen architecture presentation where it seemed like event sourcing took DDD hostage, just using it as a vehicle to sell that particular astronaut-ism. Not even a ubiquitous language...

Re: Domain-Driven Design

#39

Post by macando »

tragomaskhalos wrote: post #33
macando wrote: post #20

Earlier quoted context omitted.

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.

It's an over-reliance on ceremony. On some days I think it's a character trait.

Re: Domain-Driven Design

#40

Post by [deleted] »

macando wrote: post #20
oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

[deleted]
Post reply on HN