I've read several books on DDD and was on a team that fully bought into the idea and attempted to implement it for five years. After all that, I think the conc

I've read several books on DDD and was on a team that fully bought into the idea and attempted to implement it for five years. After all that, I think the concept of a ubiquitous language is excellent. Everyone should standardize on a common set of vocabulary. We even took it so far as to have a dictionary of our business domain terms. It's so obvious in hindsight that it seems completely foolish to do anything else. The rest of the book is basically just one guy's preferred way to organize a CRUD codebase. You can use his preferred terms (entities, repositories, value objects) and put things in the "right places" based on how he really liked to organize the codebase on this one job he did. After trying sincerely to follow this book for five years, I now think this has very little value. I don't particularly care what he thinks is the difference a service and a repository. When we had a need that wasn't obvious from the book, we'd sit in on countless meetings of people arguing the definitions while quoting the DDD book like it's a sacred text. Endless bike shedding about one guy's favorite way to organize a CRUD app isn't a high value use of a team's time. Neither is spending weeks renaming and moving everything to match the perfect terms. We bought into the idea that if we followed this guy's favorite organization, everything would be better. It wasn't. We spent a huge amount of time reorganizing 1.5 million lines of c#. I don't think we ever even gained a week back of that time. It was a huge waste of time for what? To feel good that we were following some book? We didn't reduce or remove any bugs. We didn't find it magically easier to add new domain logic, if anything it was harder because we had to debate every feature to ensure it was designed "correctly" according to the will of Eric Evans. For example, look at this snippet from the article > "Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate." Imagine trying to read an entire book filled with this kind of language. Lots of new terms, special rules, and vague reasoning. It's perfect for creating an environment of religious debate. Today I think that books (Riting Software is another) that just prescribe an organization are a waste of time. They promise benefits for just using new special terms and putting logic in the "right place" but then don't deliver. It's just one dude's preferred names for things, not a magic recipe. A better option for learning architecture in my experience is books like "Structure and Interpretation of Computer Programs" that teach excellent fundamentals. Data structures, algorithms, functions, state lifecycles, asynchronous code, dynamic code generation, and DSLs are far more valuable and people rarely give them enough time. Once I got very comfortable with those fundamentals did architecture appear to me as just the same concepts repeated at a larger scale. Drilling fundamentals was highly valuable, and I wished I'd spent more time on those early instead of reading books about DDD.