Comment by smt88
6 years ago
> Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me.
This is very narrow-minded. DDD as a broad concept is good and something I practice.
DDD in enterprise is a disastrous nightmare. When people on your team are wasting time Googling lingo to try to figure out what kind of object they need, where to put a file, or where a method should go, it's a huge red flag.
I was on a team that seemingly spent all its time trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to do it.
> When people on your team are wasting time Googling lingo to try to figure out what kind of object they need, where to put a file, or where a method should go, it's a huge red flag.
I agree, but for a different reason. If you've got a team of programmers on a project without any understanding of what the client is doing you're bound to implement stuff ass-backwards from the clients perspective.
DDD is fine in enterprise, but the domain does need to be communicated to all involved parties. You can't just dump a codebase on someone and expect them to get to work, that only barely works for non-DDD codebases let alone DDD codebases.
The kind of DDD this article is describing is totally different from Java-world enterprise DDD. It's DDD done right, with no 50-member OOP classes. Just a single function that can only take a type that describes your domain in a way that prevents whole classes of errors.
I think we're on the same page.
When inheriting a purist DDD project written in C#, I came across several... interesting... charts, including this one:
https://jj09.net/wp-content/uploads/2018/12/ddd-diagram-exam...
A lot of members of my team couldn't figure out where things were "supposed" to go (or what most of the terms mean) after weeks of working on the code, so they just started slapping methods anywhere and worrying about it later.
> [...] trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to prescribe it.
Well... If the carpenter needs to Google how to use a hammer and nails while at the construction side, something went terribly wrong, didn't it?
I would actually agree with you there, but I suspect that wasn't your point.
A hammer is such a simple and obvious concept that it should not need to be googled. If anybody needs to do that anyway, you should not put the blame on the carpenter, but on the guy who "designed" the hammer.
On a related note, I still very much am convinced that Don Norman's Design of Everyday Things is a great read for anyone who designs APIs; types in this argument function both as affordances and force functions, which are the exact reason why a hammer is such an obvious tool.
You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified.
That's not like a carpenter who can't use a hammer. It's like a carpenter who asks for a sketch of a project and instead receives a phone-book sized list of vague instructions that no one can agree on.
> You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified.
I imply that a dev who doesn't understand DDD in a enterprise environment, is unqualified for working with DDD in an enterprise environment.
As much as a carpenter is unqualified to be a carpenter if he doesn't know how to handle a hammer and nails.
And I appreciate all the downvotes coming in.
5 replies →