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.
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.
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.
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.
@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
if you're only ever building features for one app on one domain, you don't need to worry about this stuff. a domain of entities is something reusable across multiple applications. and a application solving use cases can be presented with multiple UIs.. in theory, it can even access multiple domains. the point of making the separations is to allow them to not be 1:1 to each other at those boundaries. the problem with "features" is that often they involve integrating several apps, and potentially several domains, so "vertical slicing" is already going to happen to get that feature into multiple places, and that's where it gets lost.
@ifatreefalse I see your point of the first part of your statement but i would add that even if you only develop a single app, vertical slicing may make sense if the app consists of multiple rather independent features. However, i am not fully getting the point of the second part " the problem with "features" is that often they involve integrating several apps, and potentially several domains, so "vertical slicing" is already going to happen to get that feature into multiple places, and that's where it gets lost." - can u give an example?
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
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.
@anasouardini If you prefer code samples then you may want to watch this video ruclips.net/video/6hIg86y9HuE/видео.html and this one ruclips.net/video/1IE8RC-IOSE/видео.html 😉
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
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.
@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 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.
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 this
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.
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.
That has to be the best call-to-action end segment I've ever seen!
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.
Wow! 11/10 my dude! Way to go!
@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
Totally agree with all the points mentioned here
if you're only ever building features for one app on one domain, you don't need to worry about this stuff. a domain of entities is something reusable across multiple applications. and a application solving use cases can be presented with multiple UIs.. in theory, it can even access multiple domains. the point of making the separations is to allow them to not be 1:1 to each other at those boundaries. the problem with "features" is that often they involve integrating several apps, and potentially several domains, so "vertical slicing" is already going to happen to get that feature into multiple places, and that's where it gets lost.
@ifatreefalse I see your point of the first part of your statement but i would add that even if you only develop a single app, vertical slicing may make sense if the app consists of multiple rather independent features. However, i am not fully getting the point of the second part " the problem with "features" is that often they involve integrating several apps, and potentially several domains, so "vertical slicing" is already going to happen to get that feature into multiple places, and that's where it gets lost." - can u give an example?
Thanks for the very good explaining
thank you
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
Clean code arch and VSA are messed up
@TellaTrix What is your alternative proposal?
Great
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.
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 ruclips.net/video/6hIg86y9HuE/видео.html and this one ruclips.net/video/1IE8RC-IOSE/видео.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 👍
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.
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