The most important thing you can do when trying to learn Domain-Driven Design is still very much Eric's book amzn.to/3b1Uqrx People are not recommending this book enough because few have actually finished it.
It has a reputation of being hard to read, which is deserved. Read a little bit every day. Or read the bold parts first, then start over to read it thoroughly.
It also has a reputation of being too academic or too theoretical. This is undeserved: it is highly pragmatic, but it approaches software design from an angle that didn't exist anywhere else before, so it introduces many concepts that seem foreign at first.
Accept that some parts will not make sense on the first go. That's ok. I'm still discovering things in there, that I have read 10y ago, but hadn't needed yet. Sometimes you need to feel the pain to understand the solution.
Do work through the modelling examples. Superficially they look like a bunch of objects, but it's the process of continuous refinement of the model that you need to learn.
I love the DDD community dearly, but my criticism is that we haven't explored many of the ideas in that book yet. A few of the concepts get all the spotlight, and newcomers therefore are only learning those ideas too, instead of learning from the source material.
Do study the community resources, there's a lot of ideas there that have expanded on Eric's work in phenomenal ways, or that explain it in more accessible ways. But don't use them as a substitute for Eric Evans' work.
Domain-Driven Design is one of the few ideas in software design that span from the micro level (code, patterns) to the meaning (models, language) to the large (systems, boundaries, integration) to the macro (systems of systems). That alone is reason to study it.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
