The BIGGEST Folder Structure MISTAKE on .NET

No video

The BIGGEST Folder Structure MISTAKE on .NET

Рет қаралды 22,210

Жыл бұрын

This is the most common mistake when organizing Projects and Solutions in .NET. It is a real onboarding nightmare for newcomers. In this video, I will show you how to use Feature Folders towards a Screaming Architecture (Clean Architecture).
💎 Be a Patreon to get the source code: / gsferreira
🔗 BLOG POST: gsferreira.com/archive/2022/t...
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
👋 HEY FRIEND
If you're new to my Channel, my name is Guilherme, but you can call me Gui if Portuguese pronunciation is not your thing.
I see myself as a Minimalist Software Craftsman. That says a lot of what I talk about here.
So, why this KZfaq channel? To share with you to simplify your life as a Developer through knowledge, technology, and practices.
If you are into those things as I do, don't forget to subscribe for new videos.
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsferreira
Visit my blog: gsferreira.com
#dotnet #hexagonalarchitecture #cleanarchitecture

Пікірлер: 63

@cheesypufs Жыл бұрын

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.

@gui.ferreira Жыл бұрын

Thanks for sharing that, Frank! Slicing into small problems is always useful. And it doesn't mean you need microservices 😜

@RawCoding Жыл бұрын

Really good advice 👍 framework / component based organisation is a big vice

@gui.ferreira Жыл бұрын

Absolutely! Thanks, Anton!

@avecesar Жыл бұрын

Cool!!.... A very simple concept, yet so powerful (and quite hard to grasp for some ppl attached to an "opinionated framework"). Thank you.

@gui.ferreira Жыл бұрын

Well said! But even outside of frameworks, I see this happening a lot. Thanks, Cesar!

@Tamer_Ali Жыл бұрын

Thanks Gui for the awesome video Could you please talk about Vertical Slice Architecture?

@gui.ferreira Жыл бұрын

It's on the content pipeline 🤫

@chrishmmr Жыл бұрын

Great video, thank you!

@gui.ferreira Жыл бұрын

Thanks for the feedback, Christopher 🙏

@DieDona Жыл бұрын

amazing, i am glad that i found your channel.

@gui.ferreira Жыл бұрын

My pleasure 🙏

@marna_li Жыл бұрын

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.

@gui.ferreira Жыл бұрын

💯 ☝️

@fieryscorpion 10 ай бұрын

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. 😢

@matswessling6600 Ай бұрын

mixing presentation layer with business is really bad though.

@david.caetano Жыл бұрын

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.

@gui.ferreira Жыл бұрын

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.

@joaovitordossantos8669 6 ай бұрын

great video! Thanks

@gui.ferreira 6 ай бұрын

Glad you liked it!

@icemanja Жыл бұрын

Great video! Using your example, would I create a feature folder in the api that contains everything related to that feature (controller, services etc)?

@gui.ferreira Жыл бұрын

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.

@empireofhearts Жыл бұрын

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

@gui.ferreira Жыл бұрын

My recommendation would be to find the bounded contexts and group features that way.

@kiss-consulting Жыл бұрын

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?

@gui.ferreira Жыл бұрын

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.

@kiss-consulting Жыл бұрын

@@gui.ferreira Thanks for sharing your thoughts :) I will try to think this way as well and see how it fits.

@gui.ferreira Жыл бұрын

@@kiss-consulting Let me know if I can help somehow.

@dfytq Жыл бұрын

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.

@gui.ferreira Жыл бұрын

You can treat each feature as a component. That means, that a feature can receive other feature by injection. Does that make sense?

@bosypuspus 10 ай бұрын

how would you do it by injection?@@gui.ferreira

@thatojadezweni Жыл бұрын

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) ?

@andreasbradahl457 Жыл бұрын

Look at 4:25

@gui.ferreira Жыл бұрын

Exactly! One of the goals is precisely trying to avoid an IOrderRepository. Thanks for sharing Andreas. 🙏

@mohamedal-qadeery6530 Жыл бұрын

What do you call this type of software architecture? Can u make video explaining this architecture ? Great video

@gui.ferreira Жыл бұрын

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. 😉

@salahayman3513 Жыл бұрын

That great but how that will be with separation of infrastructure with domain how it will the structure be

@gui.ferreira Жыл бұрын

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. kzfaq.info/get/bejne/ld96fbWfl8W3dps.html

@diegomelgar2696 Жыл бұрын

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

@gui.ferreira Жыл бұрын

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.

@diegomelgar2696 Жыл бұрын

@@gui.ferreira thanks!

@KodingKuma 8 ай бұрын

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 7 ай бұрын

I'm not sure if I agree 100% but DI overuse is for sure a big problem.

@KodingKuma 7 ай бұрын

@@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.

@yohanespradono5224 7 ай бұрын

what if we structure it like this, what do u call this? Order/ Controller/ Model/ View Product/ Controller/ Model/ View Customer/ Controller/ Model/ View

@gui.ferreira 7 ай бұрын

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.

@ikroeber 10 ай бұрын

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.

@gui.ferreira 9 ай бұрын

Grouping by bounded context?

@ikroeber 9 ай бұрын

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.

@gui.ferreira 9 ай бұрын

@@ikroeber 💯 I have other videos on the topic. I often try to not mix and match many concepts/practices in the same video.