Vertical Slice Architecture, not Layers!

Awesome content!
This is the best video about layer architecture I have seen lately. I believe people create templates with this module structure to enforce the prevention of compiling a module with a wrongly directed import statement.

I like how to say behaviours and capabilities and behaviours instead of "business requirements", which i hear quite often. Lumping these things into the "business" side of the work implies that developers have to wait for others to define those requirements, which now seem esoteric and non technical. Whereas it's just another way of looking at how the system behaves

Good points. But if these layers aren't physical separated, you will have people start directly referencing infrastructure code in your UI code. Then we're back to the 90's. There's nothing wrong with that, if your app is small.
That ☯️ thing explains it all. It's a balance and it depends.

Very detailed and good explanation about Vertical Slice Architecture. Thank you!

Good video, but now I want cake.

I have to say thats a fine piece of cohesive cake.

Grouping classes (that belong to one layer) in a single package, module or project has always been counter-intuitive for me. Just because a class has the "Controller" or the "Activity" in its name (as a suffix usually) doesn't mean you have to put all the controllers in the same holder (i.e. folder), as these classes have very little or nothing in common.
Instead, breaking down the application into the features (rather than layers) and then designing every feature as a single component/service, which contains many cohesive sub-components/classes, is a much more flexible architecture, if you later decide to, let's say, extract one feature as a micro-service or simply replace the libraries for event handling, messaging or even introduce a new DB. I am very happy this video recommends/approves this very same approach,.

One more thing, working on my bachelor thesis (ages ago...), named "The Cohesion in OOP", helped me to question the "layered" approach from the very beginning even though I had a very limited experience in software/code design, so I think it is very important to cover (or at least get familiar with) the theoretical aspects of the software engineering. It certainly helps (from my experience) to recognize and avoid the scenarios that could give you troubles in the future.

Excellent video. Very well explained. Thanks.

Amazing video and concise examples, nice work! This is a common topic and all because IDEs don't allow the creation of tags and scopes for project structure visualization. I'm currently working on an extension that allows you to create your own project layout views using annotations. Then arrange your code and files as u want ;)😉

The hell of interfaces where you need to create interface for every single thing. this implement that , that implement this.... kindly put some of you wisdom on this.

Awesome video, thanks. I wish this design was more broadly used, in projects with frameworks like Rails it's really hard to see it in use

And in the end this Single Feature is just an app/blueprint inside an old good monolith.

I need a delicious piece of that cake 🤤

Absolutely great and helpful video! Thank you, Derek!

Thank you. The content of your video is very practical and pragmatic.

filing lawsuit for grandson ..ryker ..

What you are talking about is the same thing LOL
All these talk for nothing.

Do not put several classes in a single file. It's hard to find and visualize what the code does. Single folder is fine, not a single file.

So vertical slices is about expressing the "virtual" vertical slices across a layered architecture.
My problem is that even you go great lengths to create vertical slice at some point the slices will share functionality with other slices. Excellent example is authentication and authorization, the functionality is the same for all slices. If you plug it into all or most slices it becomes a layer. At the end you do not want to directly depend on the data persistence solution, so you will build an interface and implement a service.
Slices without interacting with the domain are the definition of services?

The only thing that overthinking architecture ever did for anyone is get solutions stuck in a dependency catch-22
What software architecture has taught me over the past 20 years is that software architects are addicted to solving non-problems.
In compiled DLL languages these problems that we are trying to solve are basically build into the DLL model itself. Basically projects: the architect’s favorite folder.
Completely made up doctrines like no upstream dependencies are primarily due to how compiled languages have separate DLLs requiring each over instead of just compiling the gdámn executables from the various dependencies.
The no-circular referencing of BLs is an OOP problem, to which the solution was always staring us in the face: less architecture, not more. Functions, not BLs.
The BL itself is a failure to do the basics right in the first place. KISS and separation of concerns.
The BL is itself an encapsulation of concerns, but a function isn’t. A function can have a dependency on another function that has a dependency right back on itself, and it’s fine. We even gave it a fancy word.
These same original DLL and BL problems just keep getting more and more fancy ways of solving the same self inflicted problems of too much architecture and not getting the basics right.
What do we do when one rigid BL needs to call another rigid BL that itself depends on that other one? We pull that functionality out unto a less rigid “helper”. And those helpers are just functions. See what we did there?
Now just take that same idea to the limit and get rid of the rest of the artificial, self-inflicted rigidity, and all of these fárt-sniffing solutions to the same old problems we created for ourselves go away, by OBEYing the fundamentals of software architecture.
1) KISS
2) SoC
Do these two things and vertical slices becomes an eldritch solution to a problem that no longer exists.
Then compile your in-house code to a (A) dll, and your upstream/downstream solutions become a “wtf are you talking about? What is upstream mean?”
It means that architects treat projects like folders, but to be fair, these problems are baked into the project based OOP programming models themselves.

Excellent, really apreciate u time. Very useful.

Separating by project/dll/package, is more about independant delivery/deployment and also team dependency, so it's better to separate by project/dll/package, trying to reason in terms of Dependency Inversion Principle (from SOLID) as suggested by Clean or Hexagonal Architecture. It's about seeing deliveries as PLUGINs for an independant package.

Can you just say 'incoming coupling' (Afferent) and 'outgoing coupling' (Efferent). It's way easier to understand while in the midst of absorbing your presentation. You can name drop the official afferent/efferent - but just pivot to calling them incoming/outgoing after that. Let's make this content as approachable as possible (which I think is your goal).

Thanks man

This has been a consistent approach I have utilized for more than 15 years. I probably should have coined it sooner. Thx for the video.

Wonderful video!
I love it.

I have a question. If I share a model between features, I share property and behaviour that don't interest all the feature.
Is there a way to solve it?
Example a shared basic model only with SKU property and treats with property and method, in this way I can share logic, I can build custom model for each feature.

The same for repo. I don't delete method available on update feature.
(I understand tha I can execute a simple query instead a orm function.)

Is this a good way in your opinion?

What about same application code being used by API, or gRPC or WPF forms should we put all of those “presentation” classes together? I mostly agree except with having the controller class bundled together.

With a legacy solution, a layered monolith, how would the vertical slices be introduced into the same monolithic solution without fitting it into existing (non-clean) layers? Maybe a new project? Then vertical slices within that same project? Or a separate project or set of projects from each slice?

Doesn’t StyleCop forbid multi-class files? Silly rule but lots of devs are stuck with it.

Great video, it's a great structure for larger projects. I'm having one issue though, and I can't find where in my configuration I'm doing this wrong - When Nesting the items under a static class (22min in), it all works EXCEPT for the controller. As soon as I put the controller inside the static class, it fails to find and expose it.
Any tips on making this work?

This is brillant I wish I had the experience and knowledge you have :) thanks for the talk

First off, thank you for rounding it all up in one video, I will spread it as far as I can, with this channel you're doing the code better! Could you make an addition to this video with practical examples? I still have so many questions on what do you do when you need to communicate between features, or creating a feature that depends on multiple feature, or how do you share the same model across multiple features? Thanks again!

I think this might be your best video yet. It provides a lot of context to how you think about architecture that isn't always clear in the shorter videos. I think a lot of those will make even more sense if I re-watch them after having watched this one. This is way more than just a video about project re-organization. It's about a better way of tackling problems (features) such that you use the best code for the job. Don't create a domain layer for a simple feature that only needs crud. Doing so will be the equivalent of wearing snowshoes in summer. You can still get around, but it's going to be longer and more complicated than without them. Likewise, using CRUD for a feature with complex business rules is like walking through deep snow in just your sneakers. You're going to fall down a lot.
Anyway, great job. Super helpful!

Tbh. Lets say "modern ways" of creating software are getting more and more similar to DDD. Won't we end up using DDD?

thank you for this explanation, but I had some thoughts in my mind regarding this
as I know clean architecture is not just meant for cohesion but also meant for isolation between business logic and infrastructure, in clean architecture you need to build some sort of abstraction layer using facades and adapters to avoid technology changes, so for example if you wanted to change the database, you can build the actual implementation that matches the adapter layer and here you go you changed your infrastructure without affecting other important areas, but in vertical slice architecture, while you are grouping related things together, if you wanted to change your db to another one, how much change should be done?

1) This argument is somewhat similar to Uncle Bob's one, "screaming architecture", discussed in its book "Clean Architecture"
2) Using different projects in .NET enforces the acyclic dependencies principle, i.e., you cannot create circular dependencies. Without this division, you have to use tools like NetArchTest to have the same feature
3) For Web APIs, it is possible to use the REPR pattern (e.g. in .NET, Ardalis ApiEndpoints or FastEndpoints NuGet packages) to favor a cohesive structure of the files
4) The example of a product, discussed in the Informational and functional cohesion section, has been covered in detail in Mauro Servienti's talk "All our aggregates are wrong"
Thank you very much for your clear and thorough explanation! I prefer this longer format.
p.s. I'd really like to see a video with a list of recommended books!

Just started, already I feel I am both excited and scared.

Edit: Was better off than I thought, but still room to grow

Awesome content, learned a lot, thanks!

My Tech Lead recommended me this channel and gotta say you immediately earned a new sub🦾 Great video really. I have read about similar dicussion about Cohesion and Coupling from the Modern Software Engineering Book and I got to say spot on your thought process!

Clean Architecture is for me an upside-down architecture, the thing unchanged is located at the bottom, which is wrong since slightest change there creates a fractal of possible failures, please do not serve me the unit test excuse. And the thing advertised with clean architecture, it resolve complexity is a false statement, and is not even close to being partially true, just run a cyclomatic complexity analyser and see the rabbit hole clean architecture is. And if measurable metrics don't convince you, find a mature project with clean architecture that supports changes? and by supporting I don't mean building the whole thing. I mean updating the use case, the contracts, the persistence (data access) I bet with you is less likely tho do it because of the fireworks resulted, and probably you will implement a brand new thing.

Just realized that GraphQL is CQRS by design (query and mutation). And using Apollo Federation and extending shared types is a way of slicing a common schema model and allowing each business area to add their specific view about e.g. a "Product", which is a cohesive architecture pattern by design. The only way to mess up coupling at that point is shared libraries which may still add coupling between different business areas.

Great stuff - thank you!

If you're optimizing for number of files opened by the developer you can always put your entire code in one file :P

Multiple classes in the same file is code smell to me, even if IDE's allow you to find it. It makes it harder to modify than necessary when you don't have it collapsed when scrolling around... Especially if they have similar looking code. There's a reason why classes are per file. I agree with DDD though and organizing by logical/feature-based layers. Microservice architectures basically lend themselves to this design strategy.

I wrote a Blazor app for work a few years ago and followed the Clean Architecture structure. I've been on the hunt for a good way of structuring apps for years, and I tried it out for this app. As I was developing it, it kinda made sense. Then I deployed the app and went away for a while, doing other work. Then I had some change requests and bug fixes for the app. And looking at it now, it is a complete mess! Exactly as you describe here - files in so many different places across several projects, so making a simple change can involve changing ten different files.

At some point, I'm definitely going to rebuild the app and base it on a much simpler structure. VSA might well work for that. It'll certainly be a lot better than what I have now!

Such a convoluted solution for a non-problem.

The motivation for vertical slices is always having to dig through folders to get all the files for an entity/feature.

Whenever I find myself doing this in layered architectures, I just use my editor to search for the filenames that contain the entity name and then open those. Problem solved.

Why not organize first into features, then layers? The problem with not making layers visible in the project structure is, that in a team with different skill levels present I'd say it is almost impossible to keep any unobvious layer concept intact over time. So you WILL end up with domain logic coupled to infrastructure and application concerns.

I feel validated by this video haha. I've had this discussion and demonstrated the separation of concerns alongside cohesion to many colleagues and I'm astounded how many are perplexed by the idea because "it doesn't follow the known patterns." Thanks for sharing this video!