| I’ve gradually started to use more and more DDD principles as my project grew in the 100s of kloc. Mostly to resolve pain points from natural evolution of the codebase. For example, Repositories don’t make sense for a small project. But in a large Django project, it can be really hard to enforce sane prefetching of objects, since your QuerySet objects will silently trigger new DB lookups if they need to fetch data. So I found that defining a Repository that implements a few well-known query methods, does the right prefetches, and then Django-seal’s the QS is a nice way to encapsulate the smarts around DB fetches. As a bonus, doing this means you have a very clean stubbing point so that your tests can run without the DB, if that floats your boat (Useful if your domain models are running complex logic that could otherwise require lots of DB hits to fully test). Aggregates are a useful way of solving the problem of picking a DB transaction boundary; combined with Repositories it makes it much easier to avoid deadlocks because you always start from one of the aggregate root models, instead of potentially selecting a leaf first, that might be the second query in another transaction. If you don’t need to prefetch a mode graph and deadlocks aren’t a problem, your system might not need an architectural principle like this. Bounded contexts are the most valuable concept of them all; see Uber’a rediscovery of this concept as a way of taming their micro services complexity. It’s a great way of thinking about how to define your domain terminology, and how to talk about the boundaries where terminology should change. I think DDD is particularly useful as a Schelling Point for architecture; it’s not necessarily the very best solution for every problem, but the value of having a very well-understood system that everybody knows is not to be underestimated. The alternative would be heavily documenting your own architectural principles, which might be better-suited, but are they so much better that it’s worth giving up all of the DDD knowledge and history? Like all tools, it is better for some things than others. I think a failure mode is dogmatic adoption by architecture astronauts in systems not complex enough to justify it. But you can definitely just adopt the parts that you like and gradually migrate towards full DDD over time. |