Difference between Domain Driven Design and Clean Architecture

Question

I have been studying Clean Architecture (CA) by Robert C. Martin and have found it quite useful in promoting architectural standards for large applications. Through implementation of a case study, I have a bit of experience of how it can help build applications that are more flexible, robust and scalable. Finally I have also come into grips with its potential shortcomings (many of which are outlined in this excellent response).

My question, though, is how Clean Architecture relates to Domain Driven Design (DDD) by Eric Evans. While not quite as familiar with DDD, I have noticed many similarities between DDD and CA. So here are my questions:

1. Are there any differences between CA and DDD (other than their naming scheme)?
2. Should they be used in tandem, drawing insight from both, or should one be used over the other?

From research, the only thing I was able to find on this was that CA "uses higher level of abstraction on the business objects" sourced from here.

Answer 1

You are correct that both focus on separating the domain code from the application and infrastructure code. But that is where the similarities end.

In Clean/Hexagonal/Onion (or CHO in short) architecture, the goal of this decoupling is testability and modularity with intended effect being that the "core" of our software can be reasoned about in isolation from rest of the world.

In DDD, the main goal is to establish common language with the business experts. The separation of the domain from rest of the application code is just a side effect of this main goal. It also has some say about the design of classes as entities and aggregates, but that is only within the domain itself. It has nothing to say about design outside the domain code.

In practice, you might find that you use both at the same time. You use CHO architecture to design the whole structure of the system, with the "domain core" being isolated in it's separate modules. And then you use DDD to design this domain core in collaboration with domain experts and possibly by using DDD concepts like Entites and Aggregates.

Answer 2

DDD is a paradigm that tries to help you decide how you develop certain kinds of software by applying certain strategies and tactics. It is a fundamental part to understand the domain and create a model of it in your code that uses domain terminology to implement the domain logic. As such domain-centric designs can help with implementation and evolution of your domain logic.

Clean Architecture, as one example of domain-centric architectures, is a certain way to structure your code to achieve certain properties during evolution. In particular the domain layer can be used to implement domain logic as mentioned above. CA tells you where your domain layer is placed within your software design and how dependencies should flow across layers.

DDD merely states you should reflect your domain model in code, it does not tell you how to organize it in layers as CA does. CA does not tell you how you can align it with the domain by using strategic or tactical patterns as DDD does.

Answer 3

If you look at it from the perspective of object-orientation, there is really no visible difference at all. Both CA and DDD are procedural approaches, and try to improve on the usual procedural architectures and designs (like the Layered Architecture, etc.) by introducing some constraints that are technical in nature and somewhat arbitrary.

They differ on these arbitrary constraints. CA tries to completely isolate the data from its behavior, while DDD partly acknowledges that the application should be about whatever the business tells us, but then goes into things like data (again), transactions, and technical layers.

You could say, that while DDD is a couple of steps from procedural towards object-orientation, CA goes in the opposite direction and doubles down on separating data and logic everywhere where it can.

There are some projects with requirements where you could borrow ideas from one or both of these things, especially from DDD. However, we have object-orientation, which is superior to both in most circumstances.