Vertical Slice Architecture: How Does it Compare to Clean Architecture | .NET Conf 2023
Вставка
- Опубліковано 4 жов 2024
- Is Vertical Slice Architecture the next big thing or just as cool new kid?
Enterprise software development requires you to choose the right architecture. This session with Luke Parker will provide a realistic dive into Vertical Slice Architecture (VSA) with .NET; showcasing the potential shift from Clean Architecture (CA) to VSA.
You will learn the benefits and drawbacks of both Clean Architecture & VSA. We'll reflect on some changes to increase development speed, focusing on a modern Web API, utilising the latest C# features.
See Luke demonstrate how to architect an application that is maintainable and scalable. Utilising a template for faster development, you can get up and running very quickly if you know how!
Join us and get ahead of the curve, and be the one driving innovation in your .NET application.
Blog: aka.ms/dotnet/...
Twitter: aka.ms/dotnet/...
TikTok: aka.ms/dotnet/...
Mastodon: aka.ms/dotnet/...
LinkedIn: aka.ms/dotnet/...
Facebook: aka.ms/dotnet/...
Docs: learn.microsof...
Forums: aka.ms/dotnet/...
🙋♀️Q&A: aka.ms/dotnet-qa
👨🎓Microsoft Learn: aka.ms/learndo...
#dotnet
Don't know which livestream service you guys were using but the screensharing was lagging quite a lot both in the beginning and in the end.
Yeah I think he was explaining each of the folders around 21:00 and the screen wasn’t showing what he was explaining 😭
Nice to see a simple example without the unnecessary bloat of MediatR. Two things I would personally do different though (but yeah, opiniated :P )
1. I would keep the presentation layer out of the slices so you could substitute the UI without touching the slices.
2. I personally don't use mocks but a concept called embedded stubs to keep the test logic for infrastructure code close to the implementation. That is less brittle then setting up mocks in test classes in general and removes the need for interface types all over the place leading to less maintenance.
Another architecture style I generally use together with this is A-Frame Architecture (ref. James Shore). It's a way to keep logic and infra code decoupled by having the Application layer be a "Traffic Cop" between those layers instead of having vertical dependencies.
Great video Luke! I enjoyed the succinct explanations of each software architecture. I've been a big fan of Clean Architecture for a long time, but it doesn't work for all projects (especially technical projects (such as AI). As you mentioned, I see VSA as a tool in the toolbelt. It's helpful to be aware of it so that you can apply it when appropriate.
I've learned so much from your videos. Keep it up!
Your screen is frozen after 19:30.
Yup, and at the worst possible time too
Quite the talk! Audio could've been better but learned so much!
VLA is good, but you should still keep strategy inside the Slices.I do it a bit different. I have 3 project. UI, Application And Domain. Each Project use Vertical Slices. The Domain layer use VSA for entity features (CRUD) and other very flat technical features. The application layer uses VSA for Aggregate slices (feature where multiple entities are uses). Its great for ViewModels en WebRequestModels. I use the Application layer to make a translation between the UI and the Domain layer. At the UI layer, i just call a Slice in the Application Layer that returns a ViewModel. The UI handles the ViewModel for the UI parts. This way, i can reference the Application Later to Any UI layer, the logic is the same, but the UI can be different.
Luke Parker, thanks for a nice overview of these four architectures. Would you mind sharing the blogs that you mentioned at your intro?
I know it's for keeping the demo project simple, but it would have been great to generate the resulting project into something that shows a better separation between the API and the Application layers. I know the idea is to show how everything can be simplified, but it turns moot because then it makes it look like it's another form of monolith and gives a false idea of what really is VSA.
Showing how the Application can be plugged into an API, a Worker Service (with messaging consumers, for example) or any other type of client app, would be a better exercise to display that it can be adapted to any real life project and would prevent some unrelated comments.
Other than that, nice talk and video. We need more VSA talks about how it improves over CA.
To pros of the VSA I would also add the ease of splitting it into the actual microservices if such necessity will arise (or is actually planned down the line).
Correct me if I'm wrong, but being a monolith vs microservices is purely about how you deploy and host your application, isn't it? Not the architecture and scaffolding upon which those containers are built. The 'spaghetti' structure put forward in the beginning is more akin to n-tier architecture, no?
Software is messy because it's connected to a messy world. All of these (except spaghetti) look nice at first, until you realize that you can't just split things into nice even lines across the board. All I see here is a different folder structure. I've worked with VSA and it gets messy when the slices (esp. presentation) aren't uniform throughout your app.
Hi. Good point - any architecture or tool looks awesome in a blog post or tutorial. With VSA, the point I elude to for large apps is using the dotnet new templating engine for uniformity. Then, cross communication through domain events (mediatr notification). Another thing shown but not really mentioned for lack of time - is REPR pattern inside each slice. There's many architecture decisions not mentioned in this introductory talk :). Hope this helped
I've been working with VSA for the last 4 years at least and with several projects and I can say it's the other way around: it helped me simplify the apps I've been working and make them easier to understand by the different teams I've worked with. Code was much more succint and easy to understand, not messier. Presentation is the easiest if we're talking about an API since you only have to define your endpoints and call the requests/commands/queries so everything can be pretty clean and no need to bunch up a lot of code on controllers or endpoints.
N-tier requires physical separation between tiers, in the example case n-layer would be better suited.
Where can I find the project you showed?
in 18:52 what is the start command used there?
Use DDD (Strategic + Tactical) to figure out Vertical Slices and then implement each slice using Clean Architecture, simple 🙂
Do you name bounded contexts "Vertical Slices"?
@afouadr What you suggest is more like a modular monolith approach. VSA is usually about much more fine-grained slices than the bounded contexts you can come up with using DDD.
I personally prefer what you suggest to VSA, it allows to keep the ever-growing layers of the Clean Architecture - imposed code at control.
Problem with CA keeps being all the ceremony and forced indirection you are usually *required* to do by most implementations because you *need* to comply with the Dependency Rule, so you need to abstract every silly thing, even if there's no business or technical need to do it. All of that is what VSA spares you and that's why it's not just saying "let's make feature folders in CA".
how does this clean architecture from Onion architecture?
Reminds me of CQRS + Mediator Pattern, what's the difference?
That combination is what brought VSA.
Watch the Jimmy Bogard videos about it: the easy way of implementing VSA is by combining CQRS + Mediator and forget about the Dependency Rule from CA.
nice
Giving that "Clean" architecture is absolutely stained shit, I don't think it's hard to be better.
What tf is this?
"Architecture" is being misinterpreted to be "organisation". Moving code files into folders isn't architecture!!
Also, just by renaming UnitOfWork, Actor, Domain Entity or Service to something else doesn't mean you've come up with new architecture!
These patterns have been used in software for a long time, vertical slices is essentially what a microservice is!
All you've done is have multiple microservices like organisation of code files in the same WebAPI project. But they still have release dependencies on eachother.
If you used CQRS, you wouldn't have the so called "vertical slice" of "ReadTodo" in the same WebAPI project. So that you can deploy it seperately, scale separately etc.
Learn the existing architectures & design patterns thoroughly first before coming up with bullshit like this & clean architecture!!
its beyond awful, the idea result was a 20x code increase on a Todo application. if you looked at the same repo, you see just one big code reorganization and all the code split into 10 line cs source files. this is what happens when a jr dev over engineers an app and calls it gold.
he is a jr to me, i have 30 years professional experience. this arch is worst than anything java has came out with.
@@chuckles2040I'm learning to architect my app. Any suggestion on to where i should read about architecture?
I love how microsoft dont use their own tools, IDE RIder rather then vS :)
Luke doesn't work for Microsoft 🙂