Domain Driven Design basically means to let business logic decide on object model, and construct the rest of the code from that starting point. Instead of, say, starting off by designing db schema and build from grounds up.

When combining DDD and Python, we get some interesting use cases. For example, if there is an order class Order, we can define the following methods:

• __eq__: equal to
• __gt__: compare
• __hash__: representation

And even expressing domain concepts with exceptions:

raise OutOfStock('PAPER')

Interestingly, a common consensus is that DDD is more a way of looking at things than any specific patterns in code. And as for when it’s appropriate to apply the DDD mindset:

First of all, the thing that (sadly) few devs understand is that DDD is all about a mindset, a way of looking at things. That’s it. So you can use DDD in every project, because we still need to understand the domain first, regardless of its implementation. If it turns out the domain is just a bunch of data structures, then you don’t need to complicate your life. Especially if you are building a ‘dumb’ app i.e a UI for the database.

But if you’re building an app which needs to understand business semantics (concepts and behaviour) in order to automate things, then it’s a different story and all those DDD notions will help you build a more maintainable app.

When we shouldn’t use Domain-Driven Design approach?