Clean Architecture IS about Vertical Slicing, actually!
Вставка
- Опубліковано 24 лип 2024
- The Clean Architecture by Uncle Bob is famous for it's focus on clear separation of technical concerns. But did you know that when done right Clean Architecture has actually much more in common with the Vertical Slice Architecture than most developers believe?
"The Clean Architecture", Robert C. Martin:
blog.cleancoder.com/uncle-bob...
"Screaming Architecture", Robert C. Martin:
blog.cleancoder.com/uncle-bob...
Vertical Slice Architecture - Jimmy Bogard at NDC Conferences:
• Vertical Slice Archite...
0:00 Intro
0:21 How many developers seem to see CA
1:21 Concerns
2:07 What is "Vertical Slice Architecture"?
4:32 Concern: Code Structure
6:38 Concern: Coupling
12:34 Concern: Unnecessary abstractions
14:28 Conclusion
CREDITS: "Subscribe Button" by MrNumber112 • Free Download: Subscri...
Absolutely agree.
I started to realize that clean architecture is actually more use-case oriented than layer oriented when I really started reading the book and watch the video from Uncle Bob himself. It is very misunderstood by a lot of people that they seem to care more about the layers, coupling all the features into them, mapping out which code should go to which layer, etc. which ironically kills the intention of clean architecture itself.
Thanks for clearing things up! I really like your 4 Simple Steps to Implement Clean Architecture video as well.
@detaaditya6237 Thx a lot for your feedback!
The problem with focusing your attention on technical concerns rather than solving domain problems is that implemenations tend to become over engineered and over abstracted.
Too many devs apply such onion architecture to small projects and completely bloat them to the moon when they good solve their problem with a lot less code. The vertical slice people simply have seen too many poor implementations of onions full of feature coupling hard to update and would hope for people to first learn vertical slicing, write simple solutions and then read clean architecture when they refactor it gradually as it increases in size and scope. Not start out like that.
@Sam-jx5zy thx for sharing your experience with the community! Starting with vertical slicing and then applying separation of technical concerns as the code base/design grows is a very good advice, from my perspective
I like watching someone new to me making their take on software architecture. It's a neverending discussion and you can always learn something. Thank you.
I won't be giving my opinion on software architecture, but I want to say that it's hard. With the demand there is for software engineers, many people want just a plain simple guide on how to build software. I believe most SE would really like to build well designed systems, but the reality is it's probably comparable to art. This makes me believe that we either took a wrong path at some point or the evolution of software engineering is too slow.
I used to think of building software as an engineering activity as well but meanwhile I think it is more like crafting software. There are best practices and engineering skills are definitely required but it is also an art as well to some degree, at least from my perspective
Thank you. That use-case approach is exactly how I implement the clean architecture for years now.
Much better to find your way around a feature and very simple, if you want to transfer a feature to a different project.
Good job! I tend to use vert slice on major features or classes that are intricate to the project. In land management their are two ways of doing it, lease based or tract based and any other class that is not crucial to those entities are not vert sliced. Ppl forget that the two archs can be used in same solution.
That has to be the best call-to-action end segment I've ever seen!
Thanks for the very good explaining
Around 13:12, you made a reference to CA as a potential advantageous scenario within a software system containing 100k lines of code. However, I believe that this shouldn't be the sole determining factor. In my understanding, the uniqueness of CA lies in the division of the core into two distinct aspects: enterprise-specific (entities) and application-specific (use cases).
If there is no compelling reason to integrate your domain with other services or you dont have a rich domain, then these two aspects can already be combined, leading to the likes of hexagonal architecture or just simply the dependency inversion principle. Not that there is much abstraction going on between the two layers but at the very least that one layer is also gone.
Besides that, I pretty much agree. I kind of wish that Uncle bob revisisted CA and gave us his modern opinion. Considering he said something along the lines of " clean architecture can have as many layers as you want" but everyone just defaults to his example diagram or some kind of variant mixed up with onion architecture.
Interesting perspective - thx for sharing! I think there is also a value in separating entities and use cases if you only have a single application which has multiple use cases. Then each use case should be independent, from my perspective, and in entities you'll find the data structures and the rules valid for all use cases.
Wow! 11/10 my dude! Way to go!
Totally agree with all the points mentioned here
thank you
@AboutCleanCode should the different features be separated into different projects, or having different folders suffices?. Most solutions i see have multiple projects per feature but i often think having just separate folders is enough
I think both options are fine. The bigger a feature grows the more I would tend to a separate project
Great
Clean code arch and VSA are messed up
@TellaTrix What is your alternative proposal?
well thx for sharing, but i dont understand what the point here ? using Clean architecture with vertical slicing architecture is good or not ? or you just point out the misconception theory when some1 compare 2 kinds of architecture ? i want to focus on how to structure project by using clean architecture to ez understand the core business not by technical concern. If i was a member who just join the project, at least i would know which business i have to work with, not by technical concern (too many files, unnecessary seperation code base and so much time to read over project)
My point simply is: Clean Architecture is often presented as simple layered architecture which only foucses on separation of technical concern and from my perspective this is not correct. So in this video I want to show that CA and VSA has much more in common than usually assumed. Also CA focuses on business first, separation of technical concerns second - at least how I interpret it.
I think a big issue of developers, is over engineering stuff. Even more experience one may not notcie but they do it, learning too many concepts, model, framework and so on, trying to following strcitly you end up with this project that you show in the beginning, too complex. By Reading Clean Architecture, it should be something simple, no complex
Well said. So many straw man arguments against clean architecture from people that don't understand it.
No starwmans needed. Like with most things, what people take away from something is often not what was presented. A lot of the nuance is lost, and it can take on a life of its own. That means there are two types of clean architecture. The type that is most often seen and used is the horizontal layers where everything is organized by technical concern. That is what most people are arguing against.
Is there even one architecture that really works?
If I look at enterprise projects then everything is 10 times as complicated and takes 10 times as much time to implement. So clearly its not better~
@GnomeEU From my perspective one of the biggest challenges of enterprise projects is that those projects are usually huge and that requirements constantly change as successful business do change over time. If we try to treat architecture and architectural decisions as "static" I think all architectures will fail at some point. But if we recognize architecture as a dynamic process of modeling the business, adopting change and managing complexity then we'll be able to find the right architecture for the right context.
Words...
This makes no sense without code examples of many categories of software.
@anasouardini If you prefer code samples then you may want to watch this video ua-cam.com/video/6hIg86y9HuE/v-deo.html and this one ua-cam.com/video/1IE8RC-IOSE/v-deo.html 😉
Dsagreed, the both are needed.
You induce a confusion when comparing the two, clean is a layered architecture and a vertical sliced architecture and a ports and adapter architecture and a onion architecture.
ISP and DIP lead to more complexity, but it is simple and easy to maintain. And it is a complexity exposed, not hidden behind if-else and switch witch are difficult to read and hard to maintain. The "unecessary complexity" should be defined, because complexity is in the business but also in the context around the feature. Abstraction allow to take cross-cutting concerns into account. User may not need it, but its business certainly does
Thx for sharing your thoughts. I can follow your argumentation 👍
Just use ruby on rails and stick to it!
@julian_handpan Yeah 😁 I used it around 10 years back and it was great for rapid app development but I cannot imagine using it for bigger projects 😉
@@AboutCleanCode you kidding right ? Does GitHub sounds to you ?🤣. Rails is by far the best framework out there.
@julian_handpan honestly I didn't know that GitHub is written in Rails 🤦♂️😂 Thx for pointing out! Nevertheless, me personally, I still cannot imagine developing and maintaining such a huge project in Ruby mostly because I would miss the compiler, the static code checks and the (strong) type system so badly - at least when I used Ruby more 10 years ago no such features did exist ...
@@AboutCleanCode give it a try, there’s a lot of new gems and tools out there!
@@AboutCleanCode The same is for PHP but suddenly there are newer versions of PHP (8.0+) which are much strictier (the development direction of a new PHP versions are to clean up the language and make it more strictier) and then for the things which are not done yet, we have tools like PHPCS (code sniffer) or PHPStan (static analysis tool). and so on.. And suddenly even an PHP is very strictly typped and suitable even for bigger projects. And the same applies to NodeJS (with Typescript), and so on.. Btw. even the GitLab is written in Rails.
Too much c#
You can also find F# videos on my channel 😉
@@AboutCleanCode8:14
everything bob wrote - got misunderstood, just stop reading his books
Or start reading his books multiple times 😉
@@AboutCleanCode is he some kind of a software jesus?
Indeed. Books he wrote were written in context, where they were actual and useful. But lazy minds started treating them as a 'Holy books' one has to obey without thinking.