Why is Clean Architecture so Popular?

Why is Clean Architecture so popular? You've probably noticed many videos and blogs that somewhat explain what Clean Architecture is and show you how to use it. So it's really popular, but should it be? Should you be using it? Here's why I think it's popular, the problems it addresses, and some aspects that almost nobody ever mentions.

🔗 EventStoreDB

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

0:00 Intro
0:41 Clean Architecture
4:00 Prescription
5:16 Coupling
7:26 Cohesion (Boundaries)

#softwarearchitecture #softwaredesign #cleanarchitecture

[CodeOpinion]

If you've watched any of my other videos, you know I'm an advocate for vertical slices and focusing on features and organizing code that way. I didn't really mention them in this video directly but I plan on creating a video dedicated to it.

[beam_campus]

I have done away with terms like "Clean Architecture", "Ports and Adapters" or "Hexagonal Architecture" and just call it by its family name: "Inverted Architecture" In the end, it is just a manifestation of Inversion of Control.

[Galakyllz]

I find that if you don't setup the appropriate layers first, you never do. I've come to distrust any talk of "this app will only do X" because they always grow and become monsters (without a clean architecture). By the time you realize the problem, you end up contemplating rewriting the app from scratch.
Thanks for the video. Love this channel.

[-two]

Totally agree with this!

I'm a Solutions Architect and I constantly bang my head against a wall arguing with developers about why they dont need CQRS and DDD in a CRUD microservice. We double or even triple our development time (and testing) times because of it. We have a huge number of services and the majority of them are really simple REST API's with simple CRUD behaviour. But you open up the code and its layer after layer of abstraction for what is essentially a controller and some CRUD. Development times stretch out and individual microservices becoming overly complex for absolutely no reason other than to stick to the gold rules of "Clean Architecture". It drives me mad. Use the patterns and processes when they're relevant; not just because you've seen a video somewhere telling you its the best way to do everything..

[FISS]

Sometimes, it's beyond cohesion. When your software is large enough, even smaller pieces that don't need a business layer should have a "dummy" one just to have a consistent approach accross the entire code base.
Sometimes, when you work on a first subsystem that is built in a certain way and then you go to work on another one within the same software that is built differently might be confusing. So sometimes it is good to have everything layed out the same so developers won't need to think about how this piece is made each time they need to work on something.

[IktaSol]

More context matters. On large scale company where the turnover are high, with clean architecture people can make changes without understanding the whole system, so it's easier to get up and running. I think this is the main reason why it's so popular (also to deal with Product Manager who keeps changing requirements all the time)

[PbPomper]

I love myself a vertical slice. It makes things so much more intuitive and easier to work on.

[majormartintibor]

Good vid! There is a nice middle ground between classical mess and clean architecture that people kinda forget about: Hexagonal architecture or ports/adapaters. You have a core project which kinda is like a combination of Domain and Application. You define all interfaces in the core: primary ports for services that want to use your core and secondary ports for the core to use external stuff. So for example you define an ICarRepository as a secondary port and have the implementation in the Persistence layer. The CarRepository implements the ICarRepository defined in core, but is an internal class. Via these ports you can attach any number external systems to the core. As long as all interfaces are defined in the core and all implementations are internal you can ensure that the core has no outward dependencies. If you want to lets say refactor from using Oracle to Dapper with MSSQL as your data access you just need to implement the same interfaces and can attach via the same port.

[martabeznos]

Thanks for the video! You say pretty much the same I was thinking about this pattern and it's over-usage in simple projects/services.

[DucNguyen-vb]

LOVE your channel, straight to the point, not avoid trouble

[drewjaqua]

I think you hit the nail on the head. I love Clean Architecture, but I do think that it's popularity and subsequent misuse and over-application is a consequence of "blog driven development"

If someone really wants to understand Uncle Bob's "Clean Architecture", they need to just read his book and note a few of his Caveats:
1. It's an paradigm, not a recipe
2. There could be more layers or there could be fewer layers
3. Its not a packaging paradigm (but he details what you refer to as "horizontal" and "verticle" slices)
4. I'm pretty sure he even suggests that, as a paradigm, it's not practical for trivial projects

You brought up a *really* great point about separating the database layer from the entities layer. I think TODO lists are wholly impractical for anything but a beginners guide to MVC architecture; they simply fail to acknowledge the treacherous nature of entity relationships with respect to the separation of database layer and the entities layer.

I think your point about commingling the database layer and the entities layer for trivial applications needs to be taken to heart. I deeply appreciate that you referred to entities that bring nothing to the table as "pretendo entities" or whatever you called them #useless 😂

Great video.

[adambickford]

I think of that 'core' as the only part that isn't disposable. UIs come and go, protocols change, but the business logic is what differentiates you.

[Boss-grjw]

Context matters! Knowing when to apply Clean Architecture matters. A lot of supporting applications end up just dealing with single concern where you should never even consider it and where such technical layering is only gonna cause more overhead. Having cohesive set of business functionality is usually enough. I only apply Clean Archetecture patterns in business critical applications which are much larger. Having separate domain/aggregates which are not concerned by any tehcnical infrastructure is the only way to properly unit test core of the system. A lot of times I see large systems where business logic is tested through large and slow integration tests because the technical parts are not properly separated. This is where proper layering and direction of dependencies matter.

[csexton]

For smaller apps I tend to just take a traditional layered approach which makes any business specific code easier to separate, if any as the app grows.

[znx]

This hard separation via projects always makes me think of the explicit file ordering in fsharp. You can only depend on something that comes before it. This helps you think about what you are doing and makes looking for the important/independent code simple, since it's all at the top. It also prevents you from accidentally doing the wrong thing like coupling your domain objects to implementation details like http/database stuff as that will result in compiler errors. Presentation/implementation should be underneath/depend on the logic, not the other way around. Using projects for this separation feels like such a heavy solution.

At my job it's just what you describe: big projects divided in presentation/infra/app/domain, with countless of repositories and usecases. Most of it for what is just CRUD. Though I'm that familiair with vertical slices, this seems more like what we would actually want to keep things maintainable. Big fat chance introducing this though, since these layers are kind of holy around these parts :')

[BlazorPlate]

That is why we chose Clean Architecture for building our boilerplate template, BlazorPlate.

[frankenbeans]

In my experience, the benefits of implementing a standard for solution organizing (like this one) outweigh the cons. Having basic decisions out of the way (layers, naming, references) removes a lot of hand wringing and pontificating that happens at the beginning of a project and keeps people from reinventing the wheel over and over. Personally, I can’t stand moving from solution to solution and seeing inconsistencies. Clean architecture might be a little prescriptive. And naming and layering consistency across a portfolio of projects might be good enough for many.

[andreimclive]

Just found your channel and I am really grateful, it answers a lot of questions I always had about software architecture. Thanks

[georgehelyar]

I find when working with microservices that each service is so small that this really isn't needed. They aren't using crud, they just usually only deal with a small number of types of request, often only a single RPC endpoint or brokered event.

If I had to split a service into 4 projects, I'd probably say it means it's doing too much.

You still need to know about dependencies, coupling, etc, but it's at the level of the services rather than the classes.

[lunify]

Doesn't CA coexist with vertical slices ensuring high cohesion while maintaining a clear dependency direction? From what I understood from uncle bob explaining CA, its sole purpose is dependency direction, while his screaming architecture is used in tandem, basically applying vertical slicing with entities as the base.

I would love to hear your thoughts