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

101–110 of 198 posts

Re: Domain-Driven Design

#101

Post by arkh »

mathiasverraes wrote: post #72
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'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing in…

I think the main problem is the Blue Book (Domain Driven Design) contains mostly technical advice. If my memory is correct there's only one of the last chapter about the organizational aspect.

Implementing DDD on the other hand is a lot better about this. Surely because it has been written 10 years later. So most people should start with it.

But anyway when people say they're using DDD, if they can't point you to some domain experts, a dictionary of the ubiquitous language or a mapping of what they do they're not using DDD.

Re: Domain-Driven Design

#102

Post by oscarcp »

rewma wrote: post #96
mathiasverraes wrote: post #72

Earlier quoted context omitted.

I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing in…

> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs betw…

You make quite the point here. That is the advantage I see for DDD; you have dependency on service that may change, DDD will make your life easier when switching, otherwise there will be weeks of rewriting code. And what happens during transition times (thinking about CRM for example) where you have to keep connected to both systems?.

This said, in my situation it's like trying to kill flies with a muon cannon (fyi. this gun is fictional and it's exaggerated to drive the point), it's cool'n's*it but the same could have been done with a newspaper or your hand. To maintain the muon cannon you need the entire Fermilab team, your hand... well, it's your hand.

Apologies for the exaggeration, can't avoid it :D

Re: Domain-Driven Design

#103

Post by moonchrome »

andi999 wrote: post #63
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?

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.

I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions.

I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.

Re: Domain-Driven Design

#104

Post by eurasiantiger »

etripe wrote: post #60
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…

Good post. The technical patterns are nigh useless unless you're going all in on event sourcing and/or CQRS - and perhaps even then. KISS > DDD. To me, what matters are the strategic patterns, i.e. how you think and talk about your domain. What a lot of (microservice) software gets wrong is bounded contexts and APIs, which can be improved through event storming (discussing what kind of things happen in your domain) a…

All you need is a common vocabulary around English proper nouns and some idea of how they work together.

And then the client data has all fields named in Spanish with abbreviations, lettering and numbering everywhere.

Re: Domain-Driven Design

#105

Post by marcosdumay »

orthoxerox wrote: post #76
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…

DDD technical patterns are a weird bunch. On one hand, there are quite a few smart concepts in there. Everyone should know what aggregates are, for example. On the other hand, many of them have little to do with the basic premise of DDD. You can have DDD without these specific patterns. On the third hand, people start applying every single pattern everywhere, like they did with GoF patterns.

> On the other hand, many of them have little to do with the basic premise of DDD.

Honestly, I see no relation at all. Those technical patterns can be applied the same way whether you model your code after the domain or not, and you don't need them at all to model your code after the domain.

They look a lot like "true Agile" 2.0.

Re: Domain-Driven Design

#106

Post by eurasiantiger »

ToJans wrote: post #64
y4mi wrote: post #59

Earlier quoted context omitted.

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

Yes! When the project becomes large enough, a lot of value loss can be prevented by discovering edge cases before implementation, and DDD practically forces that to happen. Less things discovered by devs means less design cycles, which means less effort lost in design and implementation—of course only as long as proper grooming is done to avoid implementing things out of customer priority.

Re: Domain-Driven Design

#107

Post by adam_ellsworth »

Fiahil wrote: post #6

I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with experienced Java developers with deep Enterprise Software(tm) knowledge. Then, I started working as an AI Software Engineer (mix of a software engineer + devops + data scientist), and it all clicked. DDD is a wonderful design pattern for anything related to Da…

> invariant definition

What's that? I haven't encountered that terminology before.

Re: Domain-Driven Design

#108

Post by konschubert »

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 ?

People write books that could be blog posts all the time.

Most non-fiction literature is like that.

Re: Domain-Driven Design

#109

Post by rapnie »

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?

> When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)

Re: Domain-Driven Design

#110

Post by rapnie »

pydry wrote: post #73
AndrewSChapman wrote: post #50

Earlier quoted context omitted.

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? Wh…

^^ These are the kinds of questions DDD has very vague answers to IME. It handwaves about all of the most critical aspects of software development. It's very specific that, for instance, your domain model "should only be created by factories", though. It's all a bit bikesheddy.

DDD provides insights to understanding how a business works for people who are not domain experts themself, and are tasked to translate business requirements to code. This insight helps make appropriate decisions about those "most critical aspects of software development", nothing more, nothing less. Whether you use factories or not is a much lower-level technical decision far removed from the essence and rationale of 'doing DDD'.
Post reply on HN