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

81–90 of 198 posts

Re: Domain-Driven Design

#81

Post by dagw »

torginus wrote: post #31

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

very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do.

Much of DDD is common sense, what it offers is a way to be explicitly common sense. The important factors, the way I see it, is to explicitly make sure both developers and stakeholder have a shared mental model of the business process that maps to the domain in question, they all agree on which 'jargon' terms map to which parts of that model AND that that model (with the agreed upon terms) is explicitly represented in the code.

Keeping in close contact with the business domain people is most useful if you actually understand each other. Too often I've seen developers and business people using the same 'every day' word when discussing a problem and only much later do they find out that their obvious understanding of that word was very different.

Re: Domain-Driven Design

#82

Post by dm3 »

pydry wrote: post #68
dm3 wrote: post #41

Earlier quoted context omitted.

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

I find the original tactical DDD patterns as useful as the gang-of-four OOP patterns these days. Modern languages made the latter irrelevant. Modern DDD practice emphasizes getting the strategic aspects of DDD right: language and boundaries.

Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right.

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

I don't have a good answer for this. I personally try to keep my modules small so that there's not more than a ~week worth of stuff to redo if understanding of business (or business itself) changes. I often fail too.

Re: Domain-Driven Design

#83

Post by rapnie »

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.

I'd advice people new to DDD to involve themselves with understanding the Strategic Design parts first. The rationale, pros and cons for using it etc. And stay well away from tactical patterns until you know the role of DDD wrt the objectives you want to achieve. Strategic vs. tactical are completely different concerns. The problem with a lot of DDD information is that people tend to dive into tactical way to early and introduce all kinds of architecture that is not needed. Note that result of strategic analysis may well be to conclude that a simple CRUD design is the best way forward (for a subdomain or even the entire project). The non-technical domain understanding is most important, and also helps heaps in keeping your (non-technical) stakeholders in the loop throughout the development process.

Re: Domain-Driven Design

#84

Post by sweezyjeezy »

mnsc wrote: post #80
sweezyjeezy wrote: post #77

Earlier quoted context omitted.

> Now, you could make the argument "You Are Doing It Wrong(tm)" I always hate these arguments - for me, whether a particular programming paradigm is 'good' or 'bad' for an organisation comes down to: "what will my least senior developer do with this?". If it tends to produce tangled nightmares, then it's not a good paradigm, it's about how the weakest link will use it, not the strongest ones.

Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?

I agree no paradigm is particularly great for beginners - OOP leads to junior devs separating their code prematurely/inaccurately, writing horrendous inheritance trees etc., functional programming can lead to some really opaque code that feels like you're trying to solve a puzzle when reading it. I do think good principles exist however:

- try to write code that can be easily unit tested

- composition over inheritance

- immutable over mutable + avoid side effects

- avoid recursion unless your data is recursive

etc. etc.

Re: Domain-Driven Design

#85

Post by rapnie »

ajuc wrote: post #30
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 signed for a course on DDD thinking it will be about Data-Driven Design. It was about Domain-Driven Design and it's like the exact opposite. Data-DD is focus on data and keep it simple. Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application.

> Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions

Reading this I guess you followed the wrong course. One that shoved you Tactical Patterns down the throat without explaining well-enough why you should use them. DDD in the core is not about architecture, but about *common understanding* of the domain, *before* you start coding and hacking on a particular architecture. The domain understanding should help you make appropriate architecture decisions, but in now way dictate what architecture designs to use.

Re: Domain-Driven Design

#86

Post by JackFr »

goto11 wrote: post #26
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…

Developers will destroy everything good! DDD has some great ideas about how to model things and talk about things. But it is not a concrete architecture prescribing a particular number of layers or lines of code.

I read a preprint of Eric Evans book before it came out, and then bought a copy when it got published.

As someone who had been in the industry 6-7 years at that point, it really resonated - he was describing modes of success and failure I had seen but didn’t really have names for. Much of the usefulness of the book was just to put names on these things.

What has happened to ‘DDD’ in the meantime surprised me. It never occurred to me from the original book that a methodology of strict practices could emerge from it. To me that wasn’t the sense if it at all.

Re: Domain-Driven Design

#88

Post by nocture »

DDD strikes me the software version of Agile sometimes. The ideas and philosophy behind are good, but ends up being taken as a silver bullet. If you do this you will have a good architecture and your software will be well architected. Especially in the .NET world i've seen DDD being branded together with CQRS as "Clean Architecture" which in reality turns out to be a mess of layers and separations.

Re: Domain-Driven Design

#89

Post by JackFr »

lievendoclo wrote: post #66
ChicagoDave wrote: post #53

Earlier quoted context omitted.

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.

Quick-and-dirty is always dirty and rarely quick.

Re: Domain-Driven Design

#90

Post by Jenk »

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…

Much like most things engineers bitch about, the tool isn't to blame here (as you say yourself) - it's the wrong tool for the wrong job.

There's nothing about DDD that says you can't make a simple CRUD API, if that's all that is required.

DDD's principle value is one of ubiquity (sold as "Ubiquitous Language" but I posit that "Ubiquity" is more accurate) - does your code do what the organisation does, and vice versa?

Not just using the same terminology, but using the same workflow.

Now if what the organisation does is basic stuff, then your code should be basic, too.

If there is an asymmetry between what the org and code do.. there's pain.

Post reply on HN