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

91–100 of 198 posts

Re: Domain-Driven Design

#91

Post by JackFr »

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 ?

> If it’s really that simple, why are do bible sized books written on the topic ?

Money.

Re: Domain-Driven Design

#92

Post by pydry »

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?

Certainly no good general purpose programming paradigm exists. Nor will it.

The more general purpose it purports to be the vaguer and more misapplied it will end up being.

DDD could be a lot better as a movement if it tried to limit its scope a bit.

Re: Domain-Driven Design

#93

Post by rewma »

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 and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application.

That doesn't sound right. Domain-driven design is just a technique to design a data model that fits your application domain, and designs the whole application around that data model.

To put it differently, with DDD first you define a data structures, and afterwards the application is just operators over said data structure.

The only reason why in DDD you would care about whether "a penguin is a fish or a bird" is if your businesses required handling fishes or birds in fundamentally different and incompatible ways, which would require you to write special purpose code that crossed all layers.

It sounds like you've been experiencing a kind of analysis paralysis with the DDD tag.

Re: Domain-Driven Design

#94

Post by bjornsing »

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…

> more that 25 files that hold 3 or 4 lines of code at most

That sounds kind of annoying, but not very hard to understand.

Re: Domain-Driven Design

#95

Post by pydry »

dm3 wrote: post #82
pydry wrote: post #68

Earlier quoted context omitted.

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…

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

I tended to find a lot written about the former and very little written about the latter.

In fact I found essentially zero practical or actionable advice about getting the boundaries right beyond just "it's important to get it right". DDD doesnt appear to have a coherent opinion beyond that.

Not in the books nor in blog posts written about the topic.

It reminded me a bit of how scrum had a lot to say about standups (the color of that shed was well defined) but very little to say about refactoring.

Re: Domain-Driven Design

#96

Post by rewma »

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'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 between complexity and correctness.

As DDD comes up sounding like too much work to implement too much complexity that brings too little value, they flag it as a concern.

What I believe is missing from this discussion is the scenario where DDD practices are not followed and consequently teams are forced to iterate and reimplements projects or parts of it just to fit requirements that emerged because some aspects of the domain model weren't looked into. Design by accretion is largely accepted, as is technical debt, but they do have a cost.

Re: Domain-Driven Design

#97

Post by abacadaba »

dagw wrote: post #81
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 'jarg…

Nope, still means nothing too me. I'll just accept that how this bucket of words is supposed to form some cohesive methodology or pattern for anything is beyond my understanding. I'm sure some people get paid a lot of $ to implement it tho.

Re: Domain-Driven Design

#98

Post by piaste »

_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 idea is that you have a clear, strongly-typed separation between unvalidated data and validated data.

Unvalidated data (the DTO) is just the raw representation of whatever was inputed, read from storage, received from external services, etc. Any possible input should be acceptable and faithfully representable as a DTO.

Then, by passing the DTO to a validation function, you return either a validated object (a model) which is in fact constrained to only contain a legal data state; or a set of validation errors which can be acted upon.

Your business logic should operate only on validated objects, so that you can actually rely on your basic assumptions, and actual workflow rules (eg. "you can't checkout an empty cart") can be expressed and separated from trivial validation (eg. "quantity must be greater than 0").

Re: Domain-Driven Design

#100

Post by HelloNurse »

cloogshicer wrote: post #71
_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.

That's not what "Making illegal states unrepresentable" means. Let's say you're trying to parse a user object. Let's further say users always have to have a last name - a user without last name would be illegal state. Now if you're parsing some data for a user that really doesn't have a last name for some reason, there's two approaches to this problem - either you return a User with a null last name (which is essenti…

But clearly, requiring a last name is wrong. If legitimate users can lack a last name, the system needs to work without last names: probably there should be a flexible "person's name" class that encapsulates first names, last names, titles etc. instead of attaching a raw last name to users.
Post reply on HN