Are you organizing by feature? If so, what do you find the benefits to be?
@canguyen92203 жыл бұрын
Hi Thank your video, I use package by component, Could you compare "package by component" and "package by feature"?
@CodeOpinion3 жыл бұрын
That's a good question. Similar. I'd say a collection of components (or just one) could represent a feature that correlates to backend feature..I should do a video on this.
@caioavidal Жыл бұрын
I started to re-organize my game server using that approach. I started to feel the pain of having a feature spread into different spots of my application.
@kanazaca4 жыл бұрын
Please don't stop posting videos about this kinda of stuff. It's great! Good Job!
@jordanwalker70763 жыл бұрын
Just to add something, you can still decouple each particular feature into separate layers if you need to for testability or separation of concerns, e.g. decoupling your business logic (i.e. MediatR handlers) from web concerns (i.e. controllers etc.). It's just that you put those different pieces together in the same folder for discoverability. Just wanted to add in case people think decoupling within a particular feature is outdated or something.
@CodeOpinion3 жыл бұрын
Ya absolutely, I discuss this in other videos. and dare I say, putting classes (msg, handler, pipeline) in the same file!
@ryanhiebert2044 жыл бұрын
This is the right way to organize any code base, unless the technology you're using has limitations or features that require differently. Then you work around the limitations in the technology as necessary. Thank you for making a good presentation of this idea.
@CodeOpinion4 жыл бұрын
I'll keep pushing the idea with more videos like getting deeper into vertical slices.
@marouaneterai27594 жыл бұрын
Thank you for this video. I think it's a little bit like componenets in Angular, organizing by features.
@DumbGameDev4 жыл бұрын
I came from a background in Drupal, and really this is how it is done. Its taken my awhile to understand how the .Net world does thing, and it has been pretty confusing. I feel like this 'modular' approach makes a lot more sense in general. Thanks for making me feel less crazy :)
@CodeOpinion4 жыл бұрын
I assume it's the legacy of years of tutorials and books talking about layers and separation of concerns at a technical level. Just my guess.
@DumbGameDev4 жыл бұрын
@@CodeOpinion Also a lot of generic use naming for those layers.
@si-fi4 жыл бұрын
BLL between DAL and database?
@CodeOpinion4 жыл бұрын
Oops could of been the other way around, but the purpose was just to show technical layers in general. Whatever you want to call them or how you break them down.
@si-fi4 жыл бұрын
@@CodeOpinion No worries, I get where you're coming from, and at least I was paying attention :) I've seen code where devs know they are supposed to have a layer to separate business logic from data access, but don't understand why it might be done, so instead of separation of layers you just end up with duplication of layers. Good for line counts, but not much else.
@marouaneterai27594 жыл бұрын
@@si-fi I thought the same, even did some research to find out if I was wrong
@vadimprudnikov90723 жыл бұрын
How to deal with a situation when a command handler handles commands coming from a controller and a message consumer (like Kafka)? For example, the controller and the message consumer can send the PlaceOrder command. Should we have the controller, the message consumer, and the handler in one file?
@CodeOpinion3 жыл бұрын
It's up to you really. If you're using a messaging library like Brighter or NServiceBus that can send in-process and also be wired up as a consumer then it's pretty straight forward to have the controller in the same file an send in-process and the handler will also be invoked automatically from the message library if its originating from your message broker via the messaging library.
@vadimprudnikov90723 жыл бұрын
@@CodeOpinion thanks for reply! I'm Java developer actually:) since I work with junior and mid developers I always assume that they can unintentionally make mistakes with layer dependencies. So the working solution for me is to separate functionality belonging to one bounded context by something like sub-domains, and then, by technical layers. For example: ..account.domain, account.application, account.infrastructure.msg, account.infrastructure.web, role.domain, role.application, and so on. Smells like hexagonal approach, yes :) And I use the Archunit library that ensures that the dependency rules are not broken. From the first glance, you structure does work really well for MVC CRUD projects. However, I can't imagine that it will work fine in my project where we may or may not create commands from controllers, BPM engine tasks, and scheduled jobs. I just feel that putting everything to one file would be a bit messy. I could be mistaken of course. So you know that Java guys also watch your videos:) Nevertheless, it's nice to know how people think and find good solutions for their projects!
@CodeOpinion3 жыл бұрын
Absolutely, makes sense. Might be worth checking out my video on clean architecture where I touch on this. It's an example with C# but you can likely translate that to Java. kzbin.info/www/bejne/j6TCiGmDrryCedk I'd be curious if it does translate to your environment. Let me know!
@PelFox3 жыл бұрын
Would you organize within a feature by query/command? Eg. Features/Orders/Queries/GetOrderHandler Features/Orders/Commands/CreateOrderHandler Or would you seperate these out into two own features at the top level? Features/GetOrder Features/CreateOrder I feel like it's sometimes hard to know what belongs to a specific feature and what's seperate. Like if you have a controller with 5 actions, do all of these 5 belong to the same feature slice or are they seperate? They all might modify or act on the same spectrum, but they all do different things. Like your example with Change Password. Is this a subfolder of Features/Accounts ?
@PelFox3 жыл бұрын
Also, what about models that are shared between features?
@CodeOpinion3 жыл бұрын
I don't separate Commands and Queries into different folders. They live side-by-side. I generally only have a Controller with one action in it for the respective command or query.
@PelFox3 жыл бұрын
@@CodeOpinion Thanks for the reply. You have any repository where I can look for inspiration? :)
@drewjaqua29053 жыл бұрын
Intuitively, it's my preference to group code by feature. I absolutely get the argument for grouping by layer, though. I think maybe there's not a "one size fits all" approach to grouping code, tho. The argument for grouping into layers is pretty solid for projects where any given layer is used by multiple other layers residing in alternative contexts etc. In example, in an order tracking system that had both web-based and desktop-based user interfaces, I wouldn't want the web project to deploy with desktop UI code, so I'd try to keep application logic in one library, web controller logic in another library, and desktop controller logic in another library. It may seem trivial, but in terms of CI/CD, I wouldn't want to have to rebuild and redeploy the web project just because aspects of the desktop UI changed or vise versa. In contrast, the argument for grouping into features is pretty solid for projects that would be exposed to users/clients through one system boundary, be it a user interface or an API of some sort. I think open folder hysteria is a non-trivial inconvenience and I'm glad you pointed out how awkward file navigation is in such cases. Awesome video, thanks for making it!
@CodeOpinion3 жыл бұрын
Yes, I've also been in many situation where sharing a layer (class library) between web and native app. In some of those situations, I've still organized by feature included the controller in the non-web application, which is ultimately dead code. Check out this video for a more up to date video: kzbin.info/www/bejne/mYe5fpWrgNKBmw
@RasmusSchultz3 жыл бұрын
I like the idea of organizing by feature - but part of the motivation was to provide better overview, so I don't want the units cobbled together in files. I want to be able to open, say, the "password reset" feature folder, and immediately see the two controllers and two matching views required for that feature, and so on. Why make me dig through one file to discover which components make up that feature? Being able to view the list of components gives me some high level idea of what this feature consists of and how it's factored. That's what I'm missing in projects that are organized by type, and that's what I'd expect to get by organizing by feature instead.
@sahiterdis36392 жыл бұрын
You mentioned a couple of times in the video that one may have a project or a folder as representing a layer. I would like to know when a layer can be represented by a folder and when it is better to use a project. What reasons do one have to let a layer be a project instead of a folder? Thanks in advance.
@CodeOpinion2 жыл бұрын
I use folders to group related features together, not layers. I use projects usually to group features together at a higher level.
@andrewfbrown4 жыл бұрын
Gonna try this on my next MVC project. Thanks!!
@CodeOpinion4 жыл бұрын
Let me know how it works out!
@RobyMarcellino3 жыл бұрын
Thumb up, but I prefer to put every type in its own file. Thank you for sharing!
@roman_mf Жыл бұрын
Hello Derek, this is a great idea and I want to implement it in my project. I have a couple of concerns, how do we define what is a feature? How do you do it? We use the words like features so often but trying to think about it more deeply is confusing. Is it a unit of behavior of a model, or more of a logical group of behaviors? Also, is it possible that one feature depends on another? Or is it a signal about some design overlook on my side?
@janhendrikschreier4 жыл бұрын
I can see the benefits of this approach but I wonder if this a technique that requires that programmers have fully internalized the technical layers (which you still adhere to, I guess). The classical approach ensures that you don't access higher layers from lower layers simply by project references. With the feature-organization you partly loose this ability / guiding boundary. If you have experienced programmers I don't think this is an issue. For less experienced developers I could imagine that your approach is much harder to learn (but I am just guessing). What are your thoughts on this issue?
@CodeOpinion4 жыл бұрын
I just wrote a lengthy reply and for some reason it never posted. Bummer. Let me retry! I'm much more concerned with domain/business boundaries than I am technical ones. When you move into a vertical slice, you're creating smaller units that define their own dependencies. Because of this, the focus becomes more about features and capabilities and boundaries within a system than it does technical concerns. Meaning if you're creating vertical slices within a well defined boundary of a system, layers matter less because they are so narrow. You're coupling less. I'm not saying they don't matter. They do. Instead of having a data access layer that is highly coupled and used by the entire system, your data access for a vertical slice is only coupled to that vertical slice. Not sure if this answers the question or not?
@janhendrikschreier4 жыл бұрын
@@CodeOpinion it does. Thanks!
@mishamovdivar4 жыл бұрын
@@CodeOpinion I would not agree on that. I don't think Vertical slices mean you should abandon horizontal slices alltogether and put raw sql query next to a business logic, rather each horizontal layer should be split into the vertical layer. So you still have multiple projects (UI, Domain, Dal, etc) and each of those are split vertically by features.
@CodeOpinion4 жыл бұрын
@@mishamovdivar I'm not advocating abandoning horizontal technical concerns. They just are a lower level concern to me AFTER a vertical slice. In many of my previous videos/talks/blogs, I generally point out the usage of message pipelines that I use as horizontal layers within given request. These pipelines allow you to handle the horizontal technical concerns and have separation of technical concerns. eg, Auth > Validation > Data Access > Domain Logic.
@michaelhabibau2 жыл бұрын
Fantastic video, thanks for sharing.
@CodeOpinion2 жыл бұрын
Glad you enjoyed it
@muhammadazeez25784 жыл бұрын
Is this aproach still viable with Razor Pages?
@AlexS-mc3ip4 жыл бұрын
Yeah
@CodeOpinion4 жыл бұрын
I haven't really used Razor Pages to say fully, but I'd assume so.
@allannielsen47524 жыл бұрын
Have a look at this video kzbin.info/www/bejne/iYbMiJmeds2ah9k. This is the point you are interested in, but but to understand completely watch the whole thing.
@SwampyFox4 жыл бұрын
TBH - I think Razor Pages intrinsically supports this intrinsically. When you apply it to an MVC Controller based (e.g. classic), you still have to provide some code that will resolve the views based on conventions. Pages tend to "break" down to doing one thing as opposed to having a controller that can do a whole CRUD action. Not sure if that helps?
@muhammadazeez25784 жыл бұрын
@@SwampyFox it does help. Thanks!
@saikumar-vs9vip4 жыл бұрын
Can you please share code
@CodeOpinion4 жыл бұрын
Here's the eShopOnWeb fork that I have that I'm using in the examples. github.com/dcomartin/eShopOnWeb
@zimcoder3 жыл бұрын
I like the feature concept but I think putting everything in one just won't work for me.
@CodeOpinion3 жыл бұрын
If you're having no issues with the way you're organizing code now, then it's all good. I went down the this road ultimately because I wasn't happy with how layers and coupling.
@Rostgnom3 жыл бұрын
You will also like SimpleEndpoints: github.com/dasiths/SimpleEndpoints From the Readme: > The aim of this pattern is to get away from the bloated god controllers that have a million action methods and so many dependencies. By following the SimpleEndpoints pattern we keep the endpoint scoped to a small feature and lightweight which makes it easier to understand and manage. The aim is not to blur the line between the controllers and the domain layer. You can choose to dispatch the request to the domain from the endpoint or handle it in the endpoint itself. Make an informed choice based to the context.
@codingwithgyver16373 жыл бұрын
this is also seems following the S of SOLID principles too