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.

  • 3
    Clean Architecture is a software architecture. Domain-driven design is a software design technique. Mar 2, 2020 at 4:30
  • 1
    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. Mar 2, 2020 at 5:09
  • 1
    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. Mar 2, 2020 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. Mar 2, 2020 at 14:09

4 Answers 4


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.

  • 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? Mar 2, 2020 at 7:44
  • @MatthewKnill I don't know about Design Thinking, so I cannot comment on that.
    – Euphoric
    Mar 2, 2020 at 8:15
  • No problem this is a great resource if you are interested... Mar 2, 2020 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.

  • 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? Mar 2, 2020 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. Mar 2, 2020 at 9:18
  • @MathewKnill I updated my answer. Mar 2, 2020 at 9:39

Domain Driven Design is just a set of principles for modeling the core layer of an application. It is more about strategies, patterns and practices for designing the most important layer of any domain-centric architecture – the Domain/Business Layer.
CA on the other hand, just explain how should an overall system architecture look like.


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.

  • How does CA separate data and logic everywhere? The data in CA is in the entities, which can properly encapsulate that data and only provide access through a public API. I.e. through encapsulation, the entities can ensure that data and logic are bound together. Oct 13, 2020 at 11:49
  • Take a look at Uncle Bob's "Case Study Project" on this. That is how it looks in real life. Also, while you could include some logic in the entities it would be severely limited. 1. It can't really use any technology (that is separated). 2. All the interfaces between layers is data-only, defeating any encapsulation you might try. That leaves you with some trivial stuff like standalone data validations, some calculations that don't need anything else, that's about it. Oct 13, 2020 at 14:15
  • Yeah, that repo is not useful at all, because it has 0 business rules -- there are only two use cases, and they're both queries... That's why the domain is anaemic. To your other points... Oct 13, 2020 at 16:53
  • 1. That's because it's job is to encapsulate data and corresponding logic, not interface with external technologies -- the single responsibility principle. I wouldn't call that a limitation, just proper separation of responsibilities. 2. The data is still encapsulated because you can't mutate it without going through the object. The data has to get out somehow, otherwise what use is it? If objects are to interact with each other they have to be able to share their data at some level, just in such a way that they each maintain control over the validity of that data. Oct 13, 2020 at 16:53
  • Encapsulation is not just about write-protection. It is protecting knowledge. The data in an object is supposed to be a technical detail, not the API of the object. Objects interact by asking each other to perform some function, not to ask for data. Objects might return the new objects that have some of their data re-packaged, with a different semantic (this is important), but never return their internal data with their own semantic. CA is so alien to this, it is hard to even understand the reasons why someone would call CA even remotely object-oriented. Oct 13, 2020 at 18:37

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.