There's no doubt that many projects running into "technical obstacles" suffer from inadequate understanding and analysis of the domain. I've seen this more than once, e.g. in administrative/financial systems that did not have a concept of "account" or "journal" and instead kept track of changes or statuses through numerous "flags" on a database table.
Once you "discover" the right concepts (in this case, journals or accounts), then you can take apart the big ball of mud and the whole thing suddenly becomes simple (not only conceptually but also technically - the code, no more spaghetti and workarounds).
However I still maintain that the "blue book" could be half as thick as it is and would be better for it.
About the book. Yes, this is true. Many people argue that bringing a lot of technical patterns actually ruined it. Some say this brings unnecessary rigidity to the community as such since people think that you must have aggregate roots and value objects, otherwise you are not doing DDD. Or if you have repositories - you are doing DDD. Where, apparently, both are wrong. The insight to it is that without this the book most probably would not have been taken by publishers since they were telling Eric that without code there cannot be a technical book.
Today, we at least have the "Domain-Driven Design Distilled" book by Vaughn Vernon, which is quite good to start with DDD.
I do like the repositories and the aggregates, but the writing is just a tad too verbose for my taste, I see certain concepts being rephrased again and again ... getting one's point across succinctly and briefly is also an art. The concepts are good but the author should have been a little bit more self-critical about reviewing the text and stripping it down.
Well at least that's my opinion.
Maybe I'll check out the "distilled" text, I do have an interest in the concepts.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Absolutely true!
There's no doubt that many projects running into "technical obstacles" suffer from inadequate understanding and analysis of the domain. I've seen this more than once, e.g. in administrative/financial systems that did not have a concept of "account" or "journal" and instead kept track of changes or statuses through numerous "flags" on a database table.
Once you "discover" the right concepts (in this case, journals or accounts), then you can take apart the big ball of mud and the whole thing suddenly becomes simple (not only conceptually but also technically - the code, no more spaghetti and workarounds).
However I still maintain that the "blue book" could be half as thick as it is and would be better for it.
About the book. Yes, this is true. Many people argue that bringing a lot of technical patterns actually ruined it. Some say this brings unnecessary rigidity to the community as such since people think that you must have aggregate roots and value objects, otherwise you are not doing DDD. Or if you have repositories - you are doing DDD. Where, apparently, both are wrong. The insight to it is that without this the book most probably would not have been taken by publishers since they were telling Eric that without code there cannot be a technical book.
Today, we at least have the "Domain-Driven Design Distilled" book by Vaughn Vernon, which is quite good to start with DDD.
I do like the repositories and the aggregates, but the writing is just a tad too verbose for my taste, I see certain concepts being rephrased again and again ... getting one's point across succinctly and briefly is also an art. The concepts are good but the author should have been a little bit more self-critical about reviewing the text and stripping it down.
Well at least that's my opinion.
Maybe I'll check out the "distilled" text, I do have an interest in the concepts.