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.

  • 2
    Clean Architecture is a software architecture. Domain-driven design is a software design technique. – Robert Harvey Mar 2 at 4:30
  • Thanks for that... While DDD is likely more technique based, I see architecture and techniques outlined in both. Here is one of the few sources I found that outlined a comparison between the two. – Matthew Knill Mar 2 at 5:09
  • May I point out a few issues with that article? 1. "There's a construct for everything." -- False. This is what causes "pattern-based thinking" in software developers. We need more developers that know how to think for themselves and solve problems, not just folks who can follow incomplete sets of patterns. 2. "Every developer has a different name for these constructs." -- Mostly false. The vocabulary is fairly standardized, if you stick with the well-known constructs. – Robert Harvey Mar 2 at 14:06
  • Unless, of course, the author is talking about every algorithm and data structure that's ever been devised and the ones that haven't been thought of yet, in which case, of course, there's a construct for everything and folks do tend to give them novel names. I'm not sure what that has to do with a comparison between DDD and CA, though, two concepts that are already very clearly defined. DDD is largely about naming things: what is this business process? How can we describe it in words we both understand? CA is largely about program structure and separation of concerns. – Robert Harvey Mar 2 at 14:09

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.

| improve this answer | |
  • 1
    I understand that this could open up a whole new ballpark. However, from this, would it suffice to say that DDD is closer to Design Thinking than CHO? – Matthew Knill Mar 2 at 7:44
  • @MatthewKnill I don't know about Design Thinking, so I cannot comment on that. – Euphoric Mar 2 at 8:15
  • No problem this is a great resource if you are interested... – Matthew Knill Mar 2 at 9:40

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.

| improve this answer | |
  • Just to clarify, are you saying that CA is more focussed on the finer details of software development whereas DDD is focussed on designing through the use of domain experts? – Matthew Knill Mar 2 at 7:48
  • I am not sure whether finer details is the term I would use. In a way DDD with its tactical patterns is more detailed on how to structure a domain model. But it merely says that it should be reflected in code, not anything about how the code should be organized in layers. Both have a different perspective, not the same on different levels of detail. – Hyggenbodden Mar 2 at 9:18
  • @MathewKnill I updated my answer. – Hyggenbodden Mar 2 at 9:39

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.