Domain-driven design (DDD) or just domain-oriented design (DOD)?

A minimalist DDD approach

Domain thinking has been one of the most influential aids in my software engineering. Going through the process of creating DDD-style microservices, in a carefully crafted domain design, was career-changing. Once your eyes are opened they cannot be made undone. In all my projects afterward I felt myself circle back to core domain-driven principles. However, DDD is not always allowed/needed/applicable. But I found a more lightweight approach to your software project is almost universally beneficial. I call this domain-oriented instead of domain-driven.

Domain-oriented or domain-driven design

So let's discover what a lightweight DDD approach looks like. Modern cloud-native software platforms that have a microservice orientation have become common in the past ten years. In my consulting life, it has become a rarity when an organization asks for a non-microservice solution. Domain thinking got popular as the organization of microservice needed direction.

Some teams took the opportunity to pick up on DDD tools to shape their landscape. So did I. This architecture style gave me joy, understanding, confidence, and appreciation of my code. It deeply resonated with me. There is something elegant to creating understandable aggregates. However, there are some situations where full-fledged DDD might not be a good fit:

• small or simple projects
• experimentation phase (makes it unnaturally costly)
• too many junior developers in the teams
• streaming software
• Serverless platforms to some extent (Serverless/lambda)

Especially the last bullet bugs me, as I am a huge fan of Serverless. Of course, there are possibilities to create an aggregate-like solution, but I have yet to encounter a satisfactory one. So far, this space has been occupied with blogs with creative custom solutions and lacks formalized solutions.

So, without DDD on the code level, what are we left with?

I believe that even without taking a DDD approach that brings your problem space all the way into code, you can still do it, domain-oriented.

So why domain-oriented? I needed a word that describes an approach that is DDD inspired on the system level (services, communication, and bounded context), without drawing people into code-level DDD thinking like aggregates. The visualization below depicts domain-oriented as a portion of the entire DDD spectrum.

Pros and cons of domain-oriented design

In engineering every decision has trade-offs. Architecture is all about decision-making, so let's review some advantages and disadvantages.

Advantages

• Easier for engineering teams to understand (DDD can be hard to learn).
• Still retains DDD’s architecture organization/architecture qualities.
• Easier to get accepted into your engineering community.

Disadvantages

• Missing code-level DDD constructs that codify business rules in an elegant way.
• Missing out on code-level constructs could potentially codify the domain language worse (compensation and design can be added).

Wrap-up

Domain-oriented design as a term can help to flag your high-level DDD intentions. The organization of your IT landscape into domains in a modern microservice implementation has great benefits, regardless of code-level implementations.