This is a great advice... I've been using the vertical slice architecture pattern as a way to segment the code structure by features recently and it definitely makes it easier to onboard new developers.
This is a great topic. I have been thinking about it a lot when experimenting with my own projects. Sort stuff by "feature" rather than technical concerns. You should not really worry about having everything in one project if you have some logic behinds what you do. Don't worry about mixing presentation with business logic. And I understand the feeling that beginners have, I used to wonder how to best organize files with classes. I tried by technical concerns, but you just end with jumping around folders with no view over stuff. And Layered architecture is not better.
Clean architecture is the worst thing to happen to .NET community. I despise that thing with passion and I get stressed working on any project with clean architecture. 😢
Even though I can see some advantages on adopting the vertical slices folder structure, I do not believe this is some kind of golden hammer. Ideally, IMO, IDE tools should abstract the file structure underneath and provide multiple logical tree views over the existing files, where each scenario (whether it's a command handler layer refactor or the development of a new use case) has its own optimal "file" view.
And it's not the only solution. There are always tradeoffs and decisions to be made. Besides that, I prefer to not rely too much on tooling. Tooling should come on top of it as a productivity booster but not as The Solution. I prefer to keep things simple, and don't expect that everyone is using the same tooling, knows how to use it, or even if the different tools support the same features.
Vertical slice at some point will need to join up anyways. I don't think IDE did slice it the wrong way but only give you the basics. Another thing to really consider is to have consistent namespace and folder structure name. So I would generally slice it through the technical functionality since namespace is going to give hints on what it does anyway. If anything people are doing microservice now days. I still believe that it's harder to dig through technical concepts in between projects than the business aspect of it. I've seen a place that overuse DI and we all off to chase tail like crazy. Without technical space segregation, it's extremely hairy. Not saying heavy DI mistake was a good thing, but it was a "bad culture" at some point in the past.
@@gui.ferreira When you have 1 business logic per class and everything returns an IAction just because the endpoint does, with galore interceptors on any cross cutting concerns to the point that startup time is 15 - 30 seconds, yeah, that's overuse for sure.
Can we go one more step to add Orders Folder and move all order related into that. that way we can still have order repository? you will see overall features and then sub features underneath
It's a concept that you align with ideas from Screaming Architecture (Clean Architecture), Feature Folders, or Vertical Slice Architecture. I'm planning on doing a video on the last one. 😉
sounds great, but what about if you need to use the addorder interface in some other places, you will need to duplicate/inherit the same interface again.
What’s the proper name of that “pattern” of restructuring into folder such as AddOrder. Would it be nice to know if you apply a concept to convey it to our teams and have a common terminology
It's a practice with many names in fact. Generally is named as "Feature Folders". On Clean Architecture is called "Screaming Architecture". Recently, it's been a common practice with Vertical Slice Architecture. You can find me talking about some of those concepts in many videos on the channel.
Great video! Using your example, would I create a feature folder in the api that contains everything related to that feature (controller, services etc)?
Yes. I would group everything that leaves inside of the API regarding that feature. As an example, on MVC, you have Model, View, and Controller in the same folder.
An even better way of doing this would be to use separate namespaces and folders for different contexts. It would be closer to a domain-driven approach.
Bounded contexts are sometimes implicit in our way of modeling things. I would rather say that it's better to stick to one folder for each subdomain in our modeling. It's similar to a feature-sliced approach. It's just one of hundreds of ways of doing this. My favorite one.
It depends on how you approach your architecture. As an example, take a look at this video where I talk about Clean Architecture and Vertical Slice Architecture. There, you will see how this concept applies to both, in a distinct project structure. th-cam.com/video/_yJJRn2_SFg/w-d-xo.html
I like this setup, and after I started using FastEndpoints and the REPR patterns for my APIs this is how I strive to do it. However there are cross cutting concerns that are hard to place correctly, such as error handlers, loggers, security handlers, etc. How do you structure these into a features based project structure?
That's a good point. I also struggle with that sometimes. The framework that I came up with to handle it is: 1. Am I sure that this is not a feature? For example, everything regarding Authentication can go into an Authentication folder. 2. Is it an infrastructure concern of this adapter? For example, a request logging middleware. In that case, I like to add it to an "Infrastructure/Logging" folder.
what if we structure it like this, what do u call this? Order/ Controller/ Model/ View Product/ Controller/ Model/ View Customer/ Controller/ Model/ View
I'm not sure if there's a common name for that. What you are doing there, is MVC per domain concept. It's better than inverting the order, however, it suffers from some of the same problems.
what happens in cases where for the IOrderRepository for example, it is used by multiple features (AddOrder & CancelOrder). Would it be that the interface would lie in a “Common” folder or would one decompose the interface further to its individual methods (e.g. IAddOrderRepository, ICancelOrderRepository) ?
This is a great advice... I've been using the vertical slice architecture pattern as a way to segment the code structure by features recently and it definitely makes it easier to onboard new developers.
Thanks for sharing that, Frank!
Slicing into small problems is always useful. And it doesn't mean you need microservices 😜
Really good advice 👍 framework / component based organisation is a big vice
Absolutely! Thanks, Anton!
This is a great topic. I have been thinking about it a lot when experimenting with my own projects. Sort stuff by "feature" rather than technical concerns. You should not really worry about having everything in one project if you have some logic behinds what you do. Don't worry about mixing presentation with business logic.
And I understand the feeling that beginners have, I used to wonder how to best organize files with classes. I tried by technical concerns, but you just end with jumping around folders with no view over stuff. And Layered architecture is not better.
💯 ☝️
Clean architecture is the worst thing to happen to .NET community. I despise that thing with passion and I get stressed working on any project with clean architecture. 😢
mixing presentation layer with business is really bad though.
Thanks Gui for the awesome video
Could you please talk about Vertical Slice Architecture?
It's on the content pipeline 🤫
Even though I can see some advantages on adopting the vertical slices folder structure, I do not believe this is some kind of golden hammer.
Ideally, IMO, IDE tools should abstract the file structure underneath and provide multiple logical tree views over the existing files, where each scenario (whether it's a command handler layer refactor or the development of a new use case) has its own optimal "file" view.
And it's not the only solution. There are always tradeoffs and decisions to be made.
Besides that, I prefer to not rely too much on tooling. Tooling should come on top of it as a productivity booster but not as The Solution.
I prefer to keep things simple, and don't expect that everyone is using the same tooling, knows how to use it, or even if the different tools support the same features.
amazing, i am glad that i found your channel.
My pleasure 🙏
Cool!!.... A very simple concept, yet so powerful (and quite hard to grasp for some ppl attached to an "opinionated framework"). Thank you.
Well said! But even outside of frameworks, I see this happening a lot.
Thanks, Cesar!
Vertical slice at some point will need to join up anyways. I don't think IDE did slice it the wrong way but only give you the basics. Another thing to really consider is to have consistent namespace and folder structure name. So I would generally slice it through the technical functionality since namespace is going to give hints on what it does anyway. If anything people are doing microservice now days. I still believe that it's harder to dig through technical concepts in between projects than the business aspect of it. I've seen a place that overuse DI and we all off to chase tail like crazy. Without technical space segregation, it's extremely hairy. Not saying heavy DI mistake was a good thing, but it was a "bad culture" at some point in the past.
I'm not sure if I agree 100% but DI overuse is for sure a big problem.
@@gui.ferreira When you have 1 business logic per class and everything returns an IAction just because the endpoint does, with galore interceptors on any cross cutting concerns to the point that startup time is 15 - 30 seconds, yeah, that's overuse for sure.
Great video, thank you!
Thanks for the feedback, Christopher 🙏
Can we go one more step to add Orders Folder and move all order related into that. that way we can still have order repository? you will see overall features and then sub features underneath
My recommendation would be to find the bounded contexts and group features that way.
great video! Thanks
Glad you liked it!
What do you call this type of software architecture? Can u make video explaining this architecture ? Great video
It's a concept that you align with ideas from Screaming Architecture (Clean Architecture), Feature Folders, or Vertical Slice Architecture.
I'm planning on doing a video on the last one. 😉
sounds great, but what about if you need to use the addorder interface in some other places, you will need to duplicate/inherit the same interface again.
You can treat each feature as a component. That means, that a feature can receive other feature by injection.
Does that make sense?
how would you do it by injection?@@gui.ferreira
What’s the proper name of that “pattern” of restructuring into folder such as AddOrder. Would it be nice to know if you apply a concept to convey it to our teams and have a common terminology
It's a practice with many names in fact.
Generally is named as "Feature Folders".
On Clean Architecture is called "Screaming Architecture".
Recently, it's been a common practice with Vertical Slice Architecture.
You can find me talking about some of those concepts in many videos on the channel.
@@gui.ferreira thanks!
Great video! Using your example, would I create a feature folder in the api that contains everything related to that feature (controller, services etc)?
Yes. I would group everything that leaves inside of the API regarding that feature. As an example, on MVC, you have Model, View, and Controller in the same folder.
Slice architecture on sight... Great advice...
It applies to any architecture. However, the vertical slice makes it more obvious.
An even better way of doing this would be to use separate namespaces and folders for different contexts. It would be closer to a domain-driven approach.
Grouping by bounded context?
Bounded contexts are sometimes implicit in our way of modeling things. I would rather say that it's better to stick to one folder for each subdomain in our modeling. It's similar to a feature-sliced approach. It's just one of hundreds of ways of doing this. My favorite one.
@@ikroeber 💯 I have other videos on the topic. I often try to not mix and match many concepts/practices in the same video.
That great but how that will be with separation of infrastructure with domain how it will the structure be
It depends on how you approach your architecture.
As an example, take a look at this video where I talk about Clean Architecture and Vertical Slice Architecture. There, you will see how this concept applies to both, in a distinct project structure.
th-cam.com/video/_yJJRn2_SFg/w-d-xo.html
I like this setup, and after I started using FastEndpoints and the REPR patterns for my APIs this is how I strive to do it. However there are cross cutting concerns that are hard to place correctly, such as error handlers, loggers, security handlers, etc. How do you structure these into a features based project structure?
That's a good point. I also struggle with that sometimes.
The framework that I came up with to handle it is:
1. Am I sure that this is not a feature? For example, everything regarding Authentication can go into an Authentication folder.
2. Is it an infrastructure concern of this adapter? For example, a request logging middleware. In that case, I like to add it to an "Infrastructure/Logging" folder.
@@gui.ferreira Thanks for sharing your thoughts :) I will try to think this way as well and see how it fits.
@@kiss-consulting Let me know if I can help somehow.
what if we structure it like this, what do u call this?
Order/
Controller/
Model/
View
Product/
Controller/
Model/
View
Customer/
Controller/
Model/
View
I'm not sure if there's a common name for that.
What you are doing there, is MVC per domain concept.
It's better than inverting the order, however, it suffers from some of the same problems.
what happens in cases where for the IOrderRepository for example, it is used by multiple features (AddOrder & CancelOrder). Would it be that the interface would lie in a “Common” folder or would one decompose the interface further to its individual methods (e.g. IAddOrderRepository, ICancelOrderRepository) ?
Look at 4:25
Exactly! One of the goals is precisely trying to avoid an IOrderRepository.
Thanks for sharing Andreas. 🙏
I don't like folder by type either. Folder by feature is much more easy to grow your project.
That's a good point. Growth. The benefits become clear once the project starts growing.
Awesome explanation, thanks
Thanks, John! Glad you liked it 🙏
not working good in long-term perspective
Are you brazilian?
👌👌👌
Thank you 🙏
Fail
The moment you realise that this IS the way forward, but it’s going to take a couple of days to unpick the rats nest you just carefully crafted 🫣😢
It can be done. You can do it 😉