I really liked the concepts in the video The Principles of Clean Architecture by Uncle Bob Martin. But I feel like this pattern is like a combination of Abstract Factory and Builder patterns at its core.

This is one way to write good programs but not the only way.

Rails and React are 2 frameworks that come to mind that do not promote this kind of clean architecture. Rails expects your business logic to be in the models (FatModels and SkinnyControllers), and React inside your components. Both approaches tightly couple business logic and framework code.

I don't find anything wrong in any of the 3 ways. It is a judgement call to pick any one.

But in the video I feel he suggests that clean architecture should have a clear boundary between business logic and frameworks. Frameworks (web, android, etc.) should be plugins that plug in to to the business logic. He even subtly mocks Rails in the video.

So, Is "Clean Architecture" by Bob Martin a rule of thumb for all architectures or is it just one of the options?

  • 30
    "Clean Architecture" is something that Bob Martin invented. That's it. Jun 2, 2018 at 6:12
  • 11
    Perhaps a better question is this:. Rails and React are wildly successful. What has Bob Martin written, using his Clean Architecture, to compare? I'd like to know the answer myself.
    – user949300
    Jun 2, 2018 at 6:29
  • 6
    Read Joel's blog post about five worlds, and you know why there is no "rule of thumb for all architectures".
    – Doc Brown
    Jun 2, 2018 at 7:44
  • 1
    Rails can be very successful for startups and prototyping. When time comes to maintain and develop further with 50 other developers - Rails "freedom" become an issue senior developers struggling with.
    – Fabio
    Jun 2, 2018 at 9:08
  • 1
    As if Rails was somehow special and changed the game so much that the normal rules of good design don’t apply. There is no reason that rails has to have the business rules in the active record. Keeping the business rules separate and decoupled from the ActiveRecord derivatives does not violate any Rails conventions. blog.cleancoder.com/uncle-bob/2011/11/22/…
    – dalore
    Nov 29, 2018 at 2:30

5 Answers 5


While the “Clean Architecture” is fine and has many advantages, it is important to remember that:

  • The Clean Architecture is largely Robert C. Martin's re-branding and evolution of related approaches like the Onion Architecture by Jeffrey Palermo (2008) and the Hexagonal Architecture (“Ports and Adapters”) by Alistair Cockburn and others (< 2008).

  • Different problems have different requirements. The Clean Architecture and related approaches turn decoupling, flexibility, and dependency inversion up to eleven, but sacrifice simplicity. This is not always a good deal.

The precursor to these architectures is the classic MVC pattern from Smalltalk. This disentangles the model from the user interface (controller and view), so that the model does not depend on the UI. There are many variations of MVC like MVP, MVVM, ….

More complex systems do not have just one user interface, but possibly multiple user interfaces. Many apps choose to offer a REST API that can be consumed by any UI, such as a web app or a mobile app. This isolates the business logic on the server from these UIs, so the server doesn't care which kind of app accesses it.

Typically, the server still depends on backend services such as databases or third party providers. This is perfectly fine, and leads to a simple layered architecture.

The Hexagonal Architecture goes further and stops making a distinction between frontend and backend. Any external system might be an input (data source) or an output. Our core system defines the necessary interfaces (ports), and we create adapters for any external systems.

One classic approach for strong decoupling is a service oriented architecture (SOA), where all services publish events to and consume events from a shared message bus. A similar approach was later popularized by microservices.

All of these approaches have advantages, such as making it easier to test the system in isolation (by replacing all external systems it interfaces with by mock implementations). They make it easier to provide multiple implementations for one kind of service (e.g. adding a second payment processor), or to swap out the implementation of a service (e.g. moving from an Oracle database to PostgreSQL, or by rewriting a Python service in Go).

But these architectures are the Ferrari of architectures: expensive, and most people don't need them. The added flexibility of the Clean Architecture etc. comes at the cost of more complexity. Many applications and especially CRUD webapps do not benefit from that. It makes sense to isolate things that might change, e.g. by using templates to generate HTML. It makes less sense to isolate things that are unlikely to change, e.g. the backing database. What is likely to change depends on the context and business needs.

Frameworks make assumptions about what is going to change. E.g. React tends to assume that design and behaviour of a component change together, so it doesn't make sense to separate them. Few frameworks assume that you might want to change the framework. As such, frameworks do present an amount of lock-in. E.g. Rail's reliance on the (very opinionated!) Active Record pattern make it difficult to impossible to change your data access strategy to the (often superior) Repository pattern. If your expectations of change do not match the framework, using a different framework might be better. Many other web frameworks do not make any assumptions about data access.

  • 52
    Side note: Robert C Martin has this unfortunate tendency to present something as the Best Thing Ever and suggest that this is the only sensible approach. He's usually not completely wrong. But he often omits discussion of potential drawbacks, and is prone to hyperbole. As a result, his advice tends to be misleading. It is therefore better to completely ignore anything he says.
    – amon
    Jun 2, 2018 at 9:49
  • 6
    I love hearing a statement like that, because so often I find people who blindly try to follow every little thing he says. At least if were to take the "this is one way, which often works, but always keep a wary eye" approach, I might feel better about him, but I can't really say I'm a fan of Robert Martin
    – jleach
    Jun 2, 2018 at 12:29
  • 8
    That's funny, because I recall him emphasizing that his solution wasn't the only one in the book. Then, he talked about his solution in greater depth. Personally, I don't care for some of his posts, but Clean Architecture was a great read imo. Jun 8, 2018 at 17:52
  • 4
    @bitsoflogic That's good to know! TBH I haven't read his books and my opinion is based on his talks, articles, and on questions by people who read his stuff. So far, I've seen more examples where he lacks any noticeable nuance. That's a real problem considering that Clean Code is marketed a lot to junior devs who can't yet put his opinions into context. His talk about the Clean Architecture (this question is based on a recording) does not seem to discuss limitations. For the intended audience that's fine, for anyone who considers him to be an “authority” it presents a misleading viewpoint.
    – amon
    Jun 8, 2018 at 18:24
  • 6
    Ever since I can remember, Robert Martin has had the tendency to present his ideas as if there were only benefits and no liabilities. This is a very unfortunate thing, regardless of whether you look at it from a scientific perspective or from an engineering one. Good software design is first and foremost about evaluating the tradeoffs between different solutions. If you look at classic old literature on the topic like the GoF book, they take the time to explain the drawbacks of each pattern. That's how it must be done! I wish more people were critical of Martin's dogmas like you. Feb 6, 2019 at 8:51

I really liked the concepts in the video The Principles of Clean Architecture by Uncle Bob Martin. But I feel like this pattern is like a combination of Abstract Factory and Builder patterns at its core.

Not even close.

When you look at this:

enter image description here

You are looking at the design of an object graph. This dictates what knows about what. What's missing from this story is how that object graph got built. Sorry but you won't find that here. There isn't any mention of construction.

You can construct all this without abstract factories and builders. I know because I've done it. I didn't even set out to avoid them. I love them. I just didn't happen to need them. I just used reference passing. Dependency Injection is the fancy term for that.

In fact, I could build everything you see in that diagram in main. Then just call one method on one object to start the whole thing ticking.

Now things do have to exist before you can shove them into other things. I explored that here and gave it this cute little diagram:

enter image description here

And you can build all of that without even leaving main().

I would recommend using builders and factories when you want to break up a pile of procedural construction code into nice bite sized conceptual chunks. But there is nothing in clean architecture or any of the other buzzword architectures that demands that you do. So if you want to stick with main(), fine. Just please, have mercy.

Is “Clean Architecture” by Bob Martin a rule of thumb for all architectures or is it just one of the options?

I regard Clean Architecture as a buzzword used to drive people to a blog and a book. That blog and book have very good explanations of very similar older Architectures with older names used to drive people to older blogs and older books. Specifically Onion as well as Ports and Adapters. None of which are the only architectural options you have.

I like Uncle Bob because he's an awesome public speaker and author. He makes me think of things I wouldn't have otherwise. But if you let that turn you into a religious zealot that insists everything must be done his way you'll quickly find that updating documentation is the closest I'll let you get to my code.

The buzzword architectures are useful when you have long lived code that needs to persist while the world changes around it. That's when it shines. If the world is stable in comparison to the code, then you're making things fancy for no good reason.

No matter how awesome something seems there is a context you can put it in that will make it absurd. Sorry, this isn't a silver bullet either.

But in the video I feel he suggests that clean architecture should have a clear boundary between business logic and frameworks. Frameworks (web, android, etc.) should be plugins that plug in to to the business logic. He even subtly mocks rails in the video.

You're right. He does. Uncle Bob feels that frameworks can be treated like libraries. And they can. But even that decision costs you something.

What Mr. Martin is trying to preserve is a space where your general purpose language is still general. You give that up when you spread a framework everywhere. When you do that you're heading down the path of morphing your language into something called a domain specific language. HTML is a domain specific language. It does it's job very well but there are other jobs it can't do at all.

So long as your needs are anticipated by the framework things will go very smoothly. It's nice to have your needs anticipated. It puts you in a box that keeps things simple. Just understand what you're giving up to get this. If you spread Spring everywhere you can't advertise it as as a Java job anymore. It's a Java/Spring job. I could say the same thing about Ruby and Rails but Rails ate Ruby's lunch a long time ago.


"Clean Architecture" is definitely "only" one of the options. I would argue it is one of the bad options for most projects, especially for object-oriented projects.

Here is a sentence-by-sentence analysis of Uncle Bob's article on Clean Architecture with the reasons for the above statement:

The Clean Architecture from an Object-Oriented perspective

  • 4
    This is just priceless! Everyone looking into the clean architecture should read this.
    – elad.chen
    Mar 19, 2020 at 17:20
  • The analysis is based on pure dogmatic OO point of view. While some points make sense, like the need of decoupling from framework, others are at least questionable, like putting all the possible logic, including serialization, inside a business object, etc. OOD was a popular buzzword 30 years ago, but currently I see many software to be multi-paradigm, which makes at least some of the points in the article weak.
    – Alex Che
    Jun 29, 2023 at 8:26
  • @AlexChe Interesting. I see exactly the other way around. CA argues for a given design / architecture without considering requirements. I.e. dogmatically. My article on the other hand always considers context, requirements and other factors. At no point does it say: this is the best way to do things, or something is "bad". If I would face a project where CA's assumptions apply, I would use it. I have never seen such a project in 25 years, but I may. I don't think this is a dogmatic stance. Jul 3, 2023 at 16:15

To quote the video:

"You don't want to do mail merges in SQL."

followed by:

"I actually saw a SQL stored procedure which was an entire mail merge"

The architecture, like mail merges, is just one option among many.

What's not optional are the problems which the architecture is trying to solve.

If you understand what problems the SQL mail merge causes vs other solutions, then your architectural choice will be informed and even if you are forced to choose 'bad' solutions, you will be aware of and mitigate thier shortfalls.

If you follow an architectural style just because it is well thought of, then you are likely to make mistakes and encounter the same problems.


Clean Architecture is a set of principles and patterns to address a number of common symptoms software development organizations often face over the lifetime of building complex applications. Mr. Martin goes to great lengths in the book to identify the symptoms and root causes base on his extensive experience in the field, and to clarify the role of architecture in mitigating these concerns.

However, It isn't a Rule of Thumb, nor a panacea to all ills. If you read the book, you'll have a better understanding of if/when/how to apply the principles and patterns he advocates (and the trade-offs involved). If you haven't read the book, you are likely to make incorrect assumptions, applications, judgements, and statements based on incomplete information.

  • this doesn't seem to offer anything substantial over points made and explained in 4 previous answers
    – gnat
    Dec 3, 2019 at 9:40
  • I think he pointed the fact you are not going to learn any architecture reading StackExchange's answers
    – Eneko
    Jun 6, 2020 at 9:32

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