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

71–80 of 198 posts

Re: Domain-Driven Design

#71

Post by cloogshicer »

_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 essentially giving incorrect information to the caller). Or you make it impossible to set User.lastName to null (for example by making it an Optional) and fail with an error about what went wrong.

Of course you wouldn't NEED to restrict User.lastName to never be null - but if you always fail with an error in that case anyways, why not? That way any consumer of the User object knows that the lastName will always be there and valid.

Re: Domain-Driven Design

#72

Post by mathiasverraes »

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 information, bad abstractions, etc can make it seem more complex.

Your colleagues need to remember that DDD is supposed to be applied pragmatically. If the structure causes more navigation work than needed, simplify it. If the problem could be solved with a simple CRUD system, do that. If most of the problem is CRUD, but there's one particularly complex bit that changes a lot and requires a lot of flexibility, isolate that part, so that the simple and complex parts can have a simple integration, don't leak into each other, and can evolve at their own speeds.

Re: Domain-Driven Design

#73

Post by pydry »

AndrewSChapman wrote: post #50
bamboozled wrote: post #42

Earlier quoted context omitted.

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? 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.

Re: Domain-Driven Design

#74

Post by afurculita »

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…

You don't use DDD at your current company. Naming it DDD doesn't make it DDD.

Re: Domain-Driven Design

#75

Post by nathias »

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…

This is exactly the state of a project I'm working at, but without DDD and with microservices instead. It is probably more of a general problem of complexity growth that happens when anything goes wrong with architecture and isn't addressed properly not just a consequence of bad DDD.

Re: Domain-Driven Design

#76

Post by orthoxerox »

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…

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.

Re: Domain-Driven Design

#77

Post by sweezyjeezy »

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…

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

Re: Domain-Driven Design

#78

Post by macando »

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.

Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.

Re: Domain-Driven Design

#79

Post by superzamp »

seanwilson wrote: post #7

> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…

DDD always felt like a bad adaptation of the emperor's clothes for programmers to me.

Re: Domain-Driven Design

#80

Post by mnsc »

sweezyjeezy wrote: post #77
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…

> 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?
Post reply on HN