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

41–50 of 198 posts

Re: Domain-Driven Design

#41

Post by dm3 »

pydry wrote: post #27
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…

I noticed something similar. A minimal PR to introduce DDD on our code base ballooned the codebase by something like 1,000 lines, smattered all over the code base. I think it would have ballooned it by about 12-15,000 in total in the end if we'd used it everywhere. That would have been fertile breeding ground for bugs. The ideas made sense on logically complex code that required frequent refactoring, but the strict s…

> We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things.

This is the hardest part of software design. No wonder there are no clear cut rules on how to do it. You have to be both a domain and implementation expert to get the boundaries right on the first try.

Re: Domain-Driven Design

#42

Post by bamboozled »

AndrewSChapman wrote: post #32
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?

If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?

Re: Domain-Driven Design

#43

Post by NicoJuicy »

oscarcp wrote: post #24
NicoJuicy wrote: post #21

Earlier quoted context omitted.

If it's just crud. Create a minimal API that handles it to show the difference. Which programming language? There was some work shown in .net recently

Python, FastAPI... so you can imagine how something as simple as a CRUD becomes quickly impossible to manage as soon as you ignore everything and start creating repositories, queries, use cases, etc. for a single endpoint. I agree with you that a minimal implementation should handle it but... someone had wet dreams with DDD and everything has to be DDD now :)

And for something like "translations crud" this shouldn't be required ( which service needs to be updated from a translation update?).

Perhaps that's a perfect example to implement it and push it. ( depends on how far you're willing to go and push back against who)

Look for a fancy name to describe the "pattern" could help.

Re: Domain-Driven Design

#44

Post by [deleted] »

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…

[deleted]

Re: Domain-Driven Design

#45

Post by tester34 »

DDD is a software engineering concept that if you took

100 software engineers with decade of experience,

then 30 of them would have no idea or understood it bad, and then you'd have 70 different interpretations

funny anecdote: at my last semester of eng. degree there was presentation to perform about some fancy topic. One person who had I guess like 2 or 3 years of xp decided to pick DDD and thought he'll manage to do it like a day or a few before presentation

He failed kinda hard with understanding it

Re: Domain-Driven Design

#46

Post by qaq »

bamboozled wrote: post #42
AndrewSChapman wrote: post #32

Earlier quoted context omitted.

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?

If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?

Cause consultants need to make $.

Re: Domain-Driven Design

#47

Post by latte »

The principles listed in the article look like general common-sense design principles. I can hardly imagine anyone designing a system without understanding the problem domain first - and likewise, the problem domain usually drives the underlying models (because what else can they be driven by)? I acknowledge that something the design process strays away from the original domain requirements (especially among the less experienced teams), but that usually feels wrong irrespective of the design philosophy. So the definition of DDD seems a bit tautological.

I would appreciate an explanation of what DDD is by counterexample - i.e. what are examples of non-domain driven design process? Especially, examples of successful or mostly successful projects - i.e. where the disconnect from the problem domain does not feel wrong from the start.

Re: Domain-Driven Design

#48

Post by lgvld »

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.

Ouch! Crazy ;-)

Re: Domain-Driven Design

#49

Post by davedx »

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…

My experience too. “No silver bullet” is correct. DDD has some value but the cargo culting of it gets pretty ridiculous in some places.

Re: Domain-Driven Design

#50

Post by AndrewSChapman »

bamboozled wrote: post #42
AndrewSChapman wrote: post #32

Earlier quoted context omitted.

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?

If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?

Don't get me wrong, I'm no DDD expert by any stretch.

I think the main topic and real difficultly of DDD is figuring out specifically where and how to separate out different contexts (the so-called 'bounded context' in DDD parlance).

Creating microservices is a good example. Where should the responsibility for a single microservice start and finish? What might the implications for scalability and extensibility be? What does this mean for data storage? What data will be shared or replicated between microservices and how will this be done?

Answering these kinds of questions is hard and has big implications for your teams and for your business.

Post reply on HN