Tired of Layers? Vertical Slice Architecture to the rescue!

Vertical Slice Architecture is a different way of thinking and organizing your code which is probably different from what you're used to. The primary driver becomes the features and the capabilities of your system rather than layers or separation of technical concerns. This enables you to make localized decisions per feature or feature set. That doesn't mean it's free for all of mixed concerns, such as database access and business logic. Let me explain how it works and how you have to switch your thinking.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to source code & demos!
/ @codeopinion
🔥 Don't have the JOIN button? Support me on Patreon!
/ codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
0:00 Layered Architecture
4:20 Vertical Slices
6:28 Feature Organization
9:14 CQRS & Separation of Concerns
Clean Architecture
• Why is Clean Architect...
#softwarearchitecture #softwaredesign #verticalslicearchitecture

[@thefluxlife]

I just want to add that a teammate and I were in the middle of a project where we were getting cross-eyed dealing with all the layers. And we are pretty big fans of clean architecture. However we finally decided to refactor the code into this 'vertical slice architecture' without realizing it's an actual thing. It made the code base so much easier to work with and maintain moving forward. We still followed a 'layered' approach within each vertical slice to keep things SOLID. There were a lot of cases where the code for a vertical slice could be contained within one module/file that was previously spread across 4+ files. Anecdotally I feel that this change played a huge role in pushing to production faster, increased maintainability, and understandability when sharing with other devs or dealing with context switching between other projects. It also helped new devs to the project be able to pick up support tickets faster because usually the name of the vertical slice was in the ticket and the devs didn't have to spend a lot of time hunting for the code path to investigate, etc. Finally, I also think this is a great way to _start_ a project where as clean architecture requires a lot more discernment. Great video.

[@abdullahalrashidi497]

when you say that you still use the layers inside a vertical slice, can we consider vertical slices a domain-context?

[@sharkpyro93]

@@abdullahalrashidi497 i don't see why not

[@dansmif]

I absolutely agree with keeping related files together. It's an anti-pattern called "spraying" when you've got your logically related files needlessly spread out in far away folders. I've even seen MS employees talk about this being a mistake that they regret encouraging with their older MVC project templates.

[@CodeOpinion]

Never heard the term "spraying". Interesting, thanks for the comment!

[@HakunaMatata225]

yea, wait another year or two to hear microcrap saying (as always) they were wrong again

[@gequation]

I genuinely love your short-but-concise video formula. You're a software wizard, Derek!

[@CodeOpinion]

I'm a software "something".. wizard, not exactly. 😂

[@goolom]

@@CodeOpinion believe it or not, keeping it simple, concise and cutting the off the fluff of not needed code / patterns is wizardry. Everyone says do XYZ for ABC reasons which is a ton of ritual and boilerplate code. It takes wizardry and and good mind to be more flexible without being messy There’s a reason why many people think your a wizard 🎉 you are a wizard

[@faysoufox]

What you are describing is basically a modular/smart monolith. A monolith organised by bounded business context, like microservices. Then later if needed the monolith can easily be split into microservices. The slices can even communicate with an internal message bus/mediator that later can become an external message bus like with kafka for example. So basically microservices can be seen as a well organized monolith, organised by bounded contexts/vertically, that need to scale differently depending on the bounded context.

[@CodeOpinion]

Overall yes when I'm talking about defining boundaries. Within a boundary, organizing code by features instead of layers.

[@martinrohwedder6618]

I loved your explanation of the Vertical Slice Architecture approach, and it is definately something I will try to practice in my future projects. Thank you!

[@rtzzz9772]

Thanks Derek for the clear way you have pointed this out. DP like most of the world/industries has a strong follow-the-herd mentality. Derek's approach breaks through the numbness and brings real-world practicality into CQRS.

[@leandroandrade8864]

Love the way you make things simple, pragmatic and no dogma. Thank you so much for contributing to the software "something" community 😄

[@CodeOpinion]

Thanks!

[@edgarmendoza48]

Awesome as always Derek, thank you for sharing this with us :D

[@CodeOpinion]

Glad you enjoyed it!

[@BrianHeunis]

Love your work, DC!

[@CodeOpinion]

Glad you enjoy it!

[@oscareriksson9414]

This makes sense! It's good to see some enterprice architecture/concepts that are directly about solving the problem at hand and keeping systems tidy. Well, in the business world It's going to get messy anyvway and I think it's important to remember that, still this way of thinking about complicated systems, that you group the things that belong to features is going to help new guys find their way much easier even when it's messy. If you find the folder named the choclate store, you'll find the code that work together to sell the choclate. So much better even in the worse scenario

[@CodeOpinion]

Yes, that's one of the main benefits is code is discoverable. The developer experience is better in my opinion. I'm going to have a follow up video talking about the pros/cons more in detail.

[@oscareriksson9414]

@@CodeOpinion looking forward to it! The most difficult part for many people is considering trade offs. Also, may be unrelated, but I would like to know your opinion on measuring code legability in general. For example, do you think it is useful to measure how long it takes for new members of a team to get into code bases? I figure that's what you want to optimize for, isn't it? Well of course in relation to other aspects such as performance and so on. I mean many times all you get is "follow this thing and that will make the code clean". But then nobody is measuring or really checking if that particular piece of code really is! Measuring how long something takes to get into, you can start reasoning about code ledgability. Perhaps realizing tendencies to over engineering, indirections etc.. and that way the whole team can also evolve faster. I don't care if you've got 50 years of experience, ypu can get stuck in your ways and you'll still have things to learn. Sorry about the wall of text 😁

[@haythambaidda6045]

Thank you for the brief and excellent explanation

[@CodeOpinion]

Glad it was helpful!

[@paulohincdig]

I love this approach

[@CodeOpinion]

Shout out to everyone that got the reference to "what would you say you do here".

[@marcom5331]

Thanks, great video. I was wondering if it is possibile download the VS project with vertical slice approach. Thanks

[@NNPlayaPL]

Thanks for the video. Nice to see actionable piece of advice. I learned the hard way that doing Clean Architecture without vertical slicing (or modularization as I refer to it) hurts. Question though - I found it hard to wrap my head around a project which had codebase split into small vertical slices and the domain that was unknown to me. Do you have any tips how to take care about better discoverability in such a case?

[@CodeOpinion]

Discoverability should actually be one of the main drivers. If you're naming everything based on commands/queries that are domain related, it should be really easy to find features. Eg, if I'm trying to find where the Inventory Adjustments are done in a warehouse, I'd be searching for "InventoryAdjustment", which would likely contain either all the files (commands, queries, handlers, etc) related to doing an Inventory Adjustment. This helps a lot with an IDE where you can search by class name.

[@Caldera510]

Right as I was brushing up on VSA.

[@haraheiquedossantos4283]

Great video, as always. Just to be sure about it, the OrderRepository/IOrderRepository, for example, you would put inside /Orders features folder? And the Context (EF core DbContext) you would still keeping inside /Data folder? Or would you move to a folder inside /Features called something like /Common, which the result will be /Features/Common/DataContext. This seems like a dumb questions, but I would like to know ur opinion. I have seen different ways of doing this, including people creating a /Infra folder on the root putting all the third party external configs services there (like as a mentioned the DbContext, Logging providers and all that are not particular to a specific Feature). 😅

[@CodeOpinion]

I'd put the OrderRepo or whatever else Order related within the context/boundary of Orders. If that means you have an /Orders/ folder, and all related order features there, then sure.

[@ugochukwuumerie6378]

Thank you so much. you videos has really changed my mindset on how to approach a software project. I'm currently working on a new project for my company using vertical slices (modular monolith) with one DB instance they all have logical separation with DB schema. Each slice (module) are decoupled and will be communicating via a message broker.

[@CodeOpinion]

Beyond coupling ,messaging between boundaries can go a long way to making a system more resilient

[@acymiranda]

Hi Derek, great video as usual! :-) Just a question... for the VSA approach, in your example (when you started moving files around to organize) there's a Web project and a Application project. Does both of them contain references to AspNetCore? Many tks!

[@CodeOpinion]

If you're going to put the controller together with the other code, then yes. If you don't want to take that reference, then you'd have to keep it separate.

[@acymiranda]

@@CodeOpinion Got it, tks once again! 🙂

[@maverickv3517]

Great great content. Keep it up! Thank you

[@CodeOpinion]

Thanks, will do!

[@MartinGonzalez]

How would you organize a feature folder inside, like Basket? Basket -> Application -> Domain -> Infrastructure

[@swarup2009]

A video on cross cutting concerns? We tend to put those code pieces in a folder called "common/utils" etc. Is there a recommendation on how to structure that code?

[@CodeOpinion]

Thanks for the suggestion!

[@haraheiquedossantos4283]

Good one. This question is very related with my question right above.

[@RasmusSchultz]

I love the idea of organizing by feature - but in practice, I've found it can be difficult when you have cross cutting concerns. You mentioned some examples of middleware ("russian doll") but that's not always applicable to cross cutting concerns. Practical example: there is almost definitely a tax calculation service in this project somewhere. It's going to be shared by several other features. You'll need it to calculate the cart total and on the checkout page, at least - so two different features share this concern, so you can't colocate it with either. Do you see that service as a separate feature? Or where do you put it?

[@CodeOpinion]

Share the tax calculator. Just as you would if you weren't using vertical slices. Vertical slices as mentioned doesn't imply "share nothing" or that a vertical slice can only share things that related to other features within a grouping set. Also, the assumption here is that the cart and the checkout process are different logical boundaries? Even if they are or aren't you can still share some concept of a tax calculator, just as you would any other dependency (possibly 3rd party).

[@CodeOpinion]

I plan on doing another video illustrating some of this in code.

[@martinstepanek290]

Cohesion problem in Clean Architecture causes me headache. My current solution is to split layers by projects but inside these projects structure directories by features where possible. I also use nesting of files to reduce depth and still have classes in independent files. Not ideal. To me this is more of a tooling problem. One directory structure is just not enough to allow easy orientation in code when it grows. We are forced to make choices and sacrifices. There are multiple structures that make sense and it would be nice to have some way to define them and switch views as needed. Like layers on the map.

[@cbrown940]

But how do you avoid spaghetti-ing/duplicating multiple feature slices that share the same underlying concerns - for example, a basket and a shoulder bag could share some concerns for porting items? Where do I reuse/slice their commonalities and where do I specify/architect their individualities?

[@CodeOpinion]

The simplest example is a data model. You're going to have multiple requests or features that involve the same underlying data model. You use that data model in multiple features just like you would anything else.

[@IvanRandomDude]

I guess this approach also makes it easier to switch to microservices later since each feature/set of feature can become a service if needed

[@CodeOpinion]

So as long as you aren't directly coupled (in-process) to anything from another boundary.

[@yohanespradono5224]

how do you organize the code to talk each other across features?

[@souravmojumder5563]

HI Derek .. love your videos as always! can you kindly share a github link to refer to like a template !! if possible :| thanks!

[@enverbral]

Thanks for covering this topic. A lot of people forget about cohesion when using horizontal layered architectures. I was wondering if you could go a bit deeper into this topic and talk about some practical problems you might encounter when implementing vertical layers. Specifically: how you would handle functionality that doesn't perfectly match to one feature? You might have some code that is shared by two features but doesn't really fit in or the other package. Or what about different commands from different features that share the same underlying model to perform their functionality. How would you group the model classes vs commands?

[@CodeOpinion]

Yes, I'll create another video going more in detail about the nitty gritty and specifics.

[@abdullahalrashidi497]

@@CodeOpinion please do, thank you

[@stefano_schmidt]

Asking for an advice! Do I violate any rule when 2 of my features communicate with each other (e.g., when command of one feature calls repository interface of another feature)? For example: I have 2 features: Files and Folders (representing tables in database) Whenever I add/delete a file, I also have to increase/decrease the size of a folder. Or when I delete/restore a folder, I have to mark all the files in that folder as «deleted/restored» as well. And each of them as a single transaction (i.e., add/delete file & change the folder size. Delete folder & delete files, etc.) Or should I have them as a single feature, if almost any call to one feature, ends up calling another one?

[@CodeOpinion]

I wouldn't really think of those as 2 features really on the surface, I'd think of more of them as one. You can model it together so you have the consistency you're looking for. If you don't need it to be fully consistent, they can be separate things but leverage an events to notify that a file was deleted, restored, etc so you can perform the relevant actions based on that.

[@awmy3109]

This architecture becomes messy, loses its purpose when you need to reuse logic or libraries in multiple vertical slices. Your nicely structured slices slowly morph into layered architecture. It is also harder to maintain. I personally don't want controllers and views and http interfacing logic in 10 different vertical slices. I want it in only one Web project. I don't want entity framework or database interaction code in 10 different vertical slices, I want it in only one infrastructure project. Vertical slicing should only be done in the Domain or business layer (where you have just POCOs) not the entire architecture. If you want a brief overview of what a project is about, the Domain layer is what should tell you that. The Domain layer is what is eventually split into different microservices if you want that. Layered separation of concerns is still the best and simplest for entire architecture of a monolith.

[@lunify2814]

If the vertical slices are independently deployable (distributed or microservices), code can be extracted as a separate package, using orchestrator and aggregator patterns when needed. Otherwise, if it's a distributed monolith, a shared folder does the trick. Another important realization is code duplication should be the default, until it's in 3 or 4 different places. A lot of times, code is similar but not the same. Many in the frontend learned it the hard way lately because of the shared generic components craze.

[@awmy3109]

@@lunify2814 I agree with you. The thing is if they're independently depolyable, then microservices architecture is more suitable than vertical slices.

[@goolom]

I’m glad you said this also, my experience has been identical to yours, especially with cross-cutting concerns. Very easy to become messy. Many (all) videos about vertical slice architecture say “this is the way you do things, see, it’s so easy and logical” then show a simple sample project. That’s fine I’m theory, but in practice and “large enterprise code base” the pattern is not so easy to maintain. I wish rider / Vs came with a way to organize code into temporary virtual views, similar to a solution folder so that you can aggregate classes that your working on. But this does not solve the issue that 10 related classes to a feature or action are scattered amoung 3-4 different projects (shared, application, view models as an example. ) It’s easy for 2 or more features to share the same response view model response object, such as userInfoVm (avatar, username, guid) as an example. This quickly becomes messy in large projects so we naturally make a new project, called “ViewModels” or perhaps make a folder called “InternalShared” or “InternalSharedFeatures” at the root of the feature folders, or similar. It feels “wrong to do so” - but in real-world practice I feel like it’s very hard to maintain a vertical slice architecture without code duplication. One solution would be to modularize your code and accept code duplication. But now your maintaining modules and duplicated code which is becomes a mantra and still produces the issue of “making 1 simple change is not simple because it touches so many things” Alas… control F and “go to implementation” are life savers. I still feel a bit wrong, when doing this, but I feel more wrong in duplicating code UNLESS if I have a reason to break it into modules, which is not always the case.

[@lunify2814]

​@@awmy3109 To be honest with you, I don't understand why it's called an architecture and compared to microservices. Microservices are based on vertical slices by design. In fact, it's just one evolution of service based design (which is ultimately what vertical slicing - the concept- does). All service based archs do. I remember Dave Farley mentioning different kinds in a video titled "The problem with microservices" in his channel, "Continous Delivery", in case that interests you. I agree with you when it comes to layered SoC being often the best architecture for a monolith, I'd argue it's the case even for microservices. But it's not the same as separation of files/folders representing layers. Seeing it from this angle makes it the same concept as separation of technologies that was touted as SoC on the frontend (separate HTML/CSS/JS). It's been a while since it was abandoned for the same reason: Grouping by components makes so much more sense, and that's an example of vertical slicing.

[@abdullahalrashidi497]

exactly! glad to read this .. one more benefit of layered architecture is that your mind gets shifted to the layer you're working on. for example, when you work on the model/entities layer you shouldn't think of persistence or authz layers, you're solely focused on the model itself. I think the vertical-slice by feature is not practical. however, we should vertical slice the domain boundary itself so the layers inside their own domain (since each domain would have different layers) so the video would work if we consider the feature as a domain boundary, which I think that's what Derek meant what do you think @CodeOpinion

[@MrBildo]

I've played around with vertical slicing. It works fine when you have a single UI project. Most of what we're writing at our company these days have multiple presentation layers, for example a public site and an admin site using Razor Pages and an API for our mobile app. Our Commands and Queries are shared between all these different presentation layers so we can't group the requests and handlers with the page or controller or whatever in a single file. Furthermore, events downstream are triggered by multiple different handlers so they can't be grouped like that either. The best I can do is put the request and the handler in the same file, which does help code navigation.

[@chadbennett]

Sounds like you are at a point where you do need an API layer that separates the UI from the data access / application logic. However, you could still organize the code in functional folders at both the UI and API layers. At the UI, the classes in those functional folders would call the API or directly from the razor pages, correct? Some things (ex. authentication, CC processing, shipping pricing) will need to access external services, but still can be grouped by functionality within your code. Basically putting stuff in the same project, works when it is only needed for that project. But that doesn't mean you can't organize your code by functionality even if you have to move some functionality to a external project. I hope that makes sense and is correct.

[@MrBildo]

@@chadbennett The UI is definitely separated. Each UI (Admin, Public, REST API) is it's own project. Really all the UI does is dispatch requests for queries and commands. So for sure I like this way of organizing for the "logic", but the idea of having the page/controller method, command, command handler all in one file doesn't translate when you have multiple UI's all sharing the same commands, queries, and events.

[@krccmsitp2884]

Simply: yes! 🙂

[@bunnihilator]

This is the best and most forward slice architecture explanation yet. Question - in that vertical dlice do i include its respective domain or should i create a global domain and share for all the features?

[@CodeOpinion]

A feature can be single request by itself, or it really is a set of features. Random example, a feature could be a dashboard/report. That alone is useful. A feature set maybe within a order/basket service is managing a Wishlist.. so this means adding, removing products to a Wishlist. The vertical slice of a Wishlist is (logically) independent.

[@bunnihilator]

@@CodeOpinion So, like a module.

[@bunnihilator]

@@CodeOpinion it's hard to do this separation if your domain model is the same as your entity orm model, since in the dadtabase and orm framework mapping, everything relates to everything.

[@CrapE_DM]

What I find interesting is that people do Clean Architecture, but structure their code by layer, when the writer of Clean Architecture has often said not to do that. He also supports 'vertical slicing'.

[@lunify2814]

Exactly, uncle bob has talked about screaming architecture (his version of vertical slicing) repeatedly before he even wrote about clean architecture. He also said it's an architecture for handling dependencies, not folder structure

[@CodeOpinion]

I suspect they do so to "enforce" the coupling or direction of dependencies. A request pipeline as I mentioned can be the exact same thing. A vertical slice supports direction of dependencies. But once people (me) start organizing code that way, you lose some people because they want hard project lines of dependencies.. for whatever reason. I digress.

[@ThugLifeModafocah]

I tried VSA arch in a project and I think it was a very good approach, but I faced some pitfalls on the road. I believe duplication is cheaper than the wrong abstraction (thanks to Sandi Metz), but the way I implemented the VSA was very strict with the reuse of data structures, therefore, as the project grew, adding a new field to a form required the change of "several" slices. I like the slice independecy idea, but as the same time, we need to guarantee consistency accross the system and sometimes we are pushed to reuse things. Therefore, I, now, think the next project to mix the independecy but having a shared place too. The problem is that this shared place can rebirth the wrong abstraction problem again.

[@CodeOpinion]

I'll talk about this more in a future video and give some concrete examples on how to implement it without getting into that situation.

[@mango4199]

I’m doing VSA with Layers. I’m all for organizing my folder structure by feature but I absolutely will not concede separation by technical concerns. Layers still ftw.

[@TheDibs4]

In the case of vertical slice arch, how can I use db repository? Will that be also broken down feature wise? And can there be chance of code rewrite for diff features though the code usage will be of same kind? THANKS,

[@stefano_schmidt]

Did you figure that out? I now stumbled upon all these "architecture" crap and am very confused about all this

[@dasfahrer8187]

Solid video. Would love to see something more in-depth.

[@CodeOpinion]

More to come!

[@marna_li]

Yes, I'm tired of them. I have learned from experience that layered architectures don't scale that well in big projects. I believe what is important in the development of a developer is exposure to different patterns och to see the good and the bad applications of them, and to discover when you wished used those patterns were in place - and wished not. That is how you become more open and pragmatic.

[@korayenko]

Isn't that like clean arch encapsulated in a feature? I mean, for basket feature we have basket service or basket handler in application part, we have basket domain and basket infrastructure projects all under BasketFeature subsystem.

[@CodeOpinion]

You could implement it that way, yes. Although personally I wouldn't have a "basket service" but rather just commands and queries with appropriate handlers. Handlers could be transaction scripts depending on complexity. If I needed to move towards an aggregate I would do so if complexity and consistency justified it.

[@asedtf]

I've been doing vertical slice my whole career and nobody called it that. To me it's the logical thing to do.

[@abdullahalrashidi497]

can we consider vertical slices a domain-context?

[@TheOriginalDogLP]

thanks for the insightful video, do you have any got sources on that topic for further reading?

[@CodeOpinion]

No, but beware of searching on github, because when I did last, a lot of the sample/example projects are still organizing code by technical concerns.

[@regestea]

I did something like you but the problem was if the cshtml file that moved into Application Core needed to show some images from the wwwroot folder where in the web layer we may have a problem giving the address of those images. maybe moving wwwroot into Application Core will fix that, so what is your opinion?

[@CodeOpinion]

Ultimately they all get deployed together so not sure how it matters? The file will get served at runtime.

[@MiningForPies]

Trying to implement this with a distributed monolith, the hardest bit is finding how to wire the UI up so it picks up the views from the assemblies, the documentation around it doesn’t seem to work, probably because it changes every version.

[@PaulVanGundy0]

How would ddd fit into vertical slice architecture? Reusing centralized domain logic and an associated repository layer seems opposite of vertical slice.

[@ugochukwuumerie6378]

You could make it modular. Each module is going to be a feature and you can implement whatever architecture in each module

[@CodeOpinion]

Bingo

[@torrvic1156]

Sorry…but can I keep things regards to one Feature in a separate files but in one folder? Will this be a Vertical Slices? It hurts me to see how things are bundled in one file.

[@CodeOpinion]

You can keep things in a folder. There's no rule on folder vs file. It's about putting things related together.

[@crazyfox55]

I think folders are the issue not necessarily just the code / architecture. In my opinion you should have multiple projections into your project. If I'm looking to refactor all of our services I would rather have a folder with all of them together. If I'm going to refactor the basket feature then I would rather have those in one folder. Although what I suggest might be nice there still is not a clean way to do this.

[@crazyfox55]

@Terra Former In regards to pictures, Microsoft should implement a "group by" feature that uses AI to group similar pictures together with some suggestions. Aka group by location, group by season, group by people, group by event. They can start with some basic groups and keep building from there.

[@azeemmohammed6284]

Is it possible to share this repo in github

[@kingkong2445]

Architecture = Clean + Vertical Slice

[@CodeOpinion]

I'm about to do a video about this. Your architecture is a mix bag of different architectures based on your needs.

[@manmohanmundhraa3087]

Is not it similar to microservices? feature = individual micro services. Both can use different tech stack ...

[@michaelpesin946]

After reading Lowy's Righting Software, this functional decomposition looks very problematic. This is a good structure, but it's prone for changes, because features are very volatile, can be added or changed in the short time. A team can decide on some aggregate today and change it tomorrow because of some new demand, forcing you to break the aggregate and change a lot of code. Lowy proposes deconstruction by volatility, not by functionality nor by domain, it's a great book, I recommend it to every software developer!

[@CodeOpinion]

Check out this more recent video, may give you a different perspective. kzbin.info/www/bejne/gmO6n6RmeM10f6M

[@altkev]

The problem I have with pattern discussions like this is finding good examples on how to apply them once the project has more than a basic level of complexity. Most of the examples are simple and don't work well as a reference once you try to implement them in the real world.

[@CodeOpinion]

It scales really well actually. I'll create a video in more detail about pros/cons, but managing complexity is actually the biggest benefit. My use case is 1000s of HTTP API routes with an event and message driven architecture across about 8-10 logical boundaries, all implementing vertical slices. It scales.

[@TheKabindas]

Have domain, business and data access all on one controller? Sounds like spaghetti design pattern 😁

[@CodeOpinion]

Who said to do that?

[@TheKabindas]

@@CodeOpinion I can see a lot of stuff happening from 7:59 where all is mixed (even the mediatR implementation) on GetMyOrders. I know that for video purpuses you'r just grouping by feature, nevertheless, sorry to say, i looks a bit like you described on 1:26. 🤔

[@CodeOpinion]

@@TheKabindas They are all separate classes within the same file. The controller is calling MediatR. MediatR is building a view model with EF Core. If you're referring to using EF within the GetMyOrders and not a repository, well that's a different topic. I covered it here: kzbin.info/www/bejne/ZmLPqpquq8eUpZY

[@TheKabindas]

@@CodeOpinion I see. Anyway, although I don't particularly agree with the way this implementation is done, it's always good to know that there are alternatives for very specific situations. Good thing we don't all think the same way, otherwise this world would be a bore😉. Keep up the good work and great videos 👍

[@runnerup15]

Hmm i suppose ive never been too picky about these things until people take it to extremes (interfaces folder is a sure over the line example) but the large patterns across teams seem to be controllers, business logic, data access, models, views, and maybe a static helpers folder which is not that many places to look. And the the test folders are kinda organized by pattern (in this folder all the files will look basically identical) which is not really a benefit or detractor but its an interesting side effect I guess That being said, I do kinda like the idea of this methodology; I suppose it just depends how big the service/application is

[@CodeOpinion]

Yes, to the extremes layers can get annoying. I totally forgot to mention, which I may in another video are the benefits of locating the source relevant to the feature you're changing. And second is if you're adding a feature, you're very limited to changing other files.

[@mehdi-vl5nn]

i get Django app vibes here i don't know why !

[@CodeOpinion]

Neither do I. 😂

[@sharkpyro93]

layered and clean architectures are the result of overthinking by people that don't deal with that pile of turds on a daily basis...btw do you have a vs project template available around? just wanted to see how to start a vertical project with the right foot

[@bobbycrosby9765]

In Java, we call this "package by feature, not layer". I think packaging by layer is so popular because it takes less effort. I'm one of the crazy few that uses vim to write Java code (although, I still have an IDE for refactoring). Over time my North Star in software design became "Things that change together should be closer together - those that don't should be further apart." This is a play on coupling/cohesion, but it speaks more to the developer experience so I feel like it's easier to see when things are going wrong. I think this is especially important when you aren't using an IDE, but I also think it pays off for people who aren't as knowledgeable about the specific project. The vast majority of changes I make in a project involves a vertical slice: if I need to add a new field, I'm going to have to add it to the domain, database, validation, all UIs, etc. I'm touching every layer. With package by feature, these changes are isolated to a single top-level package for the project. Layers still get their own packages - layers are features too. But that's for generic code, not feature specific code for that layer. Some things we could split up by feature we explicitly choose not to. Auth is one. We have relatively simple systems (generally < 1 million LOC), and being able to examine a single package to get a security overview is worth it for us.

[@CodeOpinion]

Yes, developer experience is something I need to mention and focus more on in another video.

[@lunify2814]

clean architecture has never been about project structure. The creator even talked about and recommended vertical slicing (called it screaming architecture) instead of structuring folders by layers, way before he wrote the blog post about clean architecture. I hope you pick up on this because I see this confusion often in your videos. CA was never about folder structure, but dependency management. The layer split should be per file for organizational and porting purposes

[@CodeOpinion]

Not sure where my confusion is? If you watch my last video about clean architecture, I pointed this out, that it's about coupling and direction of dependencies. People enforce this using projects. I don't agree with this but the reality is that's the common approach people take. You can enforce direction of dependencies using vertical slices.. that's kind of my point.

[@lunify2814]

@@CodeOpinion That is also my point and I agree with you there. Vertical slicing is awesome! The mixup is about structuring the folders following horizontal layers being a part of what CA is about (which it isn't). The culprit there is solely the fault of scaffolding tools/project generators

[@CodeOpinion]

@@lunify2814 Unfortunately yes. I wish people would see a request pipeline has the same intent. Like many things in our industry, original intent gets totally lost.. and here we are.

[@DummyFace123]

Most code that is a turdpile that I’ve seen is due to architects making things far too complicated and confusing, and people ending up putting the wrong files in the wrong projects, and giving the age old TERRIBLE advice that “only the CustomerBL should call the CustomerRepo should talk to the Customer table” and these things inevitably leading to dependency Benny hill hallways. The problem intimately is bad architects that can’t stand simplicity. They always have to overthink solutions for problems they caused in the first place

[@marcobaccaro]

You have good content, but this slice-layer organization doesn't stick.

[@CodeOpinion]

You're entitled to your own "code opinion" 😂

[@HakunaMatata225]

I really hate this industry and all the fads it produces!!.....you do realize that the Vertical slice approach still didn't solve the issue in the post you shared at 4:08, you still have to look at different files to understand how something work ( 8:48 checkout.cs, basketService.cs, BasketWithItemSpecifications...etc). whether its vertical slice or layer architecture, none of this should be called architecture, its code organization!! or to be more precise; folder and files organization!!! So, is having multiple classes in the same file ok now?! (i guess this debate will never end!!) it should be really simple, classes or code that might be shared and accessed in different files need to live in its own file! this industry is really crazy

[@CodeOpinion]

This comment deserves it's own video. I'll post the reply as a link when it's published.

[@SerZab80]

Test hell

[@CodeOpinion]

As in vertical slices are difficult to test? Not sure why that is assumed to be the case? I guess this requires a video to illustrate.

[@goolom]

@@CodeOpinion personally I would just make a test project, and organize my test structure in the same folder structure as whatever is being tested. Even the cross cutting concern. Usually I’d make an abstract test base class that is shared among all test classes within a particular feature set. Usually I duplicate the abstract test base class code and apply it to each feature, sometimes I use layered abstract test base classes to reduce code duplication (I dislike that, it seems like an accident waiting to happen) -- What would be super helpful is if you did a video on testing that tests something more than a simply unit test (unit tests videos are everywhere, in practice real applications need some sort of test that tests a feature which consumes multiple services and domain objects). Such as an integration test or some test type that tests a particular workflow among several domain objects within a single feature. This is where things get more messy and we go “free form” in organization of code, which can be good and bad, but usually messy.

[@kis.stupid]

@CodeOpinion feel free to checkout my video's and give feedback. I inspired my monorepo on Clean Architecture but more per project and type of.