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

61–70 of 198 posts

Re: Domain-Driven Design

#61

Post by afarrell »

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…

Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company?

Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?

Re: Domain-Driven Design

#62

Post by [deleted] »

ToJans wrote: post #52
y4mi wrote: post #36

Earlier quoted context omitted.

> 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 corporati…

Think about for example a planning component for hospital beds... There are a lot of parts that are really straightforward to implement, but for these planning components it might make more sense to develop an in-house component. (Assuming existing constraint solvers and/or rule engines are not a viable solution for you in this particular scenario.) If your business is talking about updating/deleting/inserting data,…

[deleted]

Re: Domain-Driven Design

#63

Post by andi999 »

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?

Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.

Re: Domain-Driven Design

#64

Post by ToJans »

y4mi wrote: post #59
ToJans wrote: post #52

Earlier quoted context omitted.

Think about for example a planning component for hospital beds... There are a lot of parts that are really straightforward to implement, but for these planning components it might make more sense to develop an in-house component. (Assuming existing constraint solvers and/or rule engines are not a viable solution for you in this particular scenario.) If your business is talking about updating/deleting/inserting data,…

You clearly have some positive experience with DDD, and I'm definitely not trying to say that DDD is broken by design or anything like that. I'm sure there are successful and maintainable projects that utilize this design approach. Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still p…

> Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still pretty convinced I'd rather implement it with less abstraction/indirection.

This example clarifies the intent behind DDD: make the implicit explicit and make sure there is awareness about all the edge cases.

It might be as simple as contacting a user in case you have an uncovered edge case, but at least you'd be aware that your system is unable to handle edge case X. (In non-DDD scenarios this would just be a bug that emerges - implicit behavior.)

Re: Domain-Driven Design

#65

Post by ToJans »

afarrell wrote: post #61
ToJans wrote: post #23

Earlier quoted context omitted.

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…

Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company? Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?

I have a few ideas, in fact I gave a talk about that a long time ago [0], but I think one of my friends Marijn gave a good suggestion on twitter [1]: don't sell DDD, but fix your the problem your boss has.

[0] https://www.slideshare.net/TomJanssens1/selling-ddd

[1] https://twitter.com/huizendveld/status/1440683623628230665

Re: Domain-Driven Design

#66

Post by lievendoclo »

ChicagoDave wrote: post #53
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 principals should only be applied to reduce complexity. If the problem space is really just crud applications, DDD modeling or engineering is a waste of time and money. But here’s where you have to be careful. It’s still useful to go through things like Event Storming and modeling domains to understand the problem space before deciding that basic crud is good enough.

I've been coding for over 15 years now and everytime someone says "Nah, we only need CRUD", they end up eating their words a couple of months down the line. The net result: domain logic all over the place. People tend to think that applying DDD infers a tremendous overhead in the code. That doesn't have to be the case. However, some tend to go overboard and that's when I can understand the frustration.

Re: Domain-Driven Design

#67

Post by orthoxerox »

HelloNurse wrote: post #34
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.

Exactly like agile, which has morphed into following the rules of the latest Agile Framework.

Re: Domain-Driven Design

#68

Post by pydry »

dm3 wrote: post #41
pydry wrote: post #27

Earlier quoted context omitted.

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 rule…

Yeah, it is tricky. I've rewritten many a code base because I drew the original boundaries in the wrong place and their logical locations only became clear in retrospect.

I'm not so convinced that it's something you can get just by better communicating with "the business" either.

This is partly what infuriated me so about the extreme amount of code required to follow DDD patterns - 3-4x the amount of code means 3-4x the cost of that rewrite if you get the boundary wrong.

Re: Domain-Driven Design

#69

Post by mathiasverraes »

The definition is highly summarised, which (like many definitions) makes it only useful if you already understand the concept, and you need a way to remember it. Or the definition can be a framework for explaining it to others, which is how I use it in workshops.

A more real world story of DDD in practice is this blog post:

https://verraes.net/2021/09/design-and-reality/

Re: Domain-Driven Design

#70

Post by nivertech »

_pmf_ wrote: post #56

"Making illegal states unrepresentable" is one of the worst possible pieces of advice I ever encountered. It sounds very reasonable, but as soon as you face the issue of communicating to the user or other components the fact that something is wrong and what is wrong, you'll discover that it is very hard to inform about illegal states if you cannot represent them.

The reason to make them unrepresentable so you will be able to catch the case when the input was illegal.

Otherwise you may never notice that illegal state was there in the first place.

I encountered many systems that would take invalid inputs and produce invalid (but sometimes even valid) results [1].

Illegal internal states are even harder to catch. When using FSM / StateCharts I usually automatically print error to log (and crash) for all illegal state/event combinations in the State Transition Table, instead of silently ignoring them.

[1] GIGO - Garbage In Garbage Out

https://en.wikipedia.org/wiki/Garbage_in,_garbage_out

Post reply on HN