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:
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:
And you can build all of that without even leaving
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.