Vertical Slice Architecture: How Does it Compare to Clean Architecture | .NET Conf 2023

[Music] all right well um I think that was a pretty cracking start to uh our live stream today um said I was really blown away I thought it was really really fascinating um how that all came together but again we're not here just to listen to to Aaron speaking for for a while um so I'm going to bring on our next presenter an next presenter is Luke parer um and he is going to be talking about uh different kinds of architectures that we've got clean architecture versus vertical slice architecture so I having seen some kind of interesting patterns there was played out with with I'm really Keen to see more on like just an architectural approach to net project so Luke let's bring your screen up and over to you for sure thanks SAR welcome everyone to this talk so today we're talking about vertical slic architecture and how it compares to clean architecture so so let's Jump Right In to start we'll jump through CA and basically how we got there so how it started and where we are at the point now where a lot of Enterprise backends are written in clean architecture then we'll talk about vertical slice architecture a little bit and similarly why we might get to the point of vertical slice architecture and then lastly I'll show a cool demo how you can get up and running with vssa using a nice net new template that I prepared earlier a little bit a little bit about me first I'm Luke Parker a software engineer currently working for ssw I'm a software architecture Guru so I'm always watching all the blogs and keeping up to date uh and I love open source newly addicted to going to the gym uh and you can look at my GitHub or blog uh at the links below so let's jump into clean architecture now to start let's talk about what happens when you have no architecture so using a web API as the example here you might have a client that hits your web API and then inside of the web API you might have a mess of three things going on usually you'll first of all have presentation logic now that could be HTTP verbs mappings routes Json serializing all of that stuff to get it over the wire then you might have business logic so you know if a value is this then set this other value as something any of that actual l in there and finally you might have some system logic so how do I eventually send this to the database so this might be EF core or some other om this of course is what we call the spaghetti architecture and it's definitely not as structured as that diagram even though it's a bit of a mess so that's start jump soor to jump back in on You Luke um I think you might not be sharing your slide deck uh I can see visual studio um that was in the I can do the screen share again I've got the slide deck up let me yeah I might just do the window if there's issues there let's jump can you see uh yes we can and this is how we can prove that we are presenting live is that we are having technical difficulties along the way all right uh back over to you [Music] now cool so I see the slides went up so I'll just go over quickly we had our diagram here with the little mess of presentation logic business logic and system logic uh and that in a CS project might look like a few folders so you might have controllers in a folder where your endpoints are so that could be the presentation logic you might have a data folder which you might call your system system logic and services could be uh your business logic now in a little spaghetti application there could be business logic in the controllers folder and a big mess like that so this is what we'd call probably the monolith now there's some per to this one right there's little to no abstraction it's very quick to build since there's no architecture you just write some codes and get it up and running there's potential keyword potential for performance abstraction comes at a cost there's CPU cycles and things like that uh however you know if you need that performance it is possible there you can do things like aot comp uh compilation and things like that there are some cons so if you're building a larger app a thing I like to call is inertia so as your system and code base increases in size the time and cost to develop new features increases basically at an exponential curve because of that and the Tangled mess it's difficult for multiple teams at once to work on that same code base and any technology change you make basically breaks the whole system since everything is so tangled together like a plate of spaghetti now similarly it's very hard to test due to the Spaghetti nature of it what if we move this and separate some of the technical concerns out so like the last diagram what if we make it very explicit in that when we come into our web API here we first do presentation logic then it depends down onto the business logic layer and it then depends down onto the data access layer eventually hitting the database in a net app this might look like three projects you could use folders anything else like that but you could have your presentation layer which obviously would be your ASP net core project uh and you'll notice in here our folders are similar you might have controllers from the previous one instead of data Maybe repositories as a folder and models and services potentially this is what we might call the end tier in this case three tiers there's pros to it it's fairly intuitive there's not tons of abstraction you just need to know that there's a few little spots for things to go it's fairly quick to build because again you're just still mainly writing code with not heaps of abstraction and there's better testability it's still not awesome we'll talk about that in a second but it's better than the monolith now there's cons to it this suffers from the same inertia problem as the spaghetti architecture where as you get a larger code base and a larger product the cost to develop increases at an exponential curve now it's difficult for multiple teams at once for that same reason it still will become a tangled mess over time technology changes impact the whole system so it's the same as the monolith what if we then move to some clarity between the business use and Technical concerns so here I've renamed a few of the terms from the previous diagram we still have our presentation layer and I've split out the data access and business logic into layers so we've got application which is primarily the business logic and domain for the sake of this diagram let's say it's just our data uh entities so it could be previously in the access layer but we've made it explicit in that the domains there now the key point is the data access layer now instead of everything being depending on it it's at the top of this diagram and doesn't depend uh doesn't have the whole system depending on it it's external to the system now this might look familiar it's the clean architecture onion here where the key thing is the core of the app in the gray layers there is the important valuable piece to the uh the buisiness or the app domain uh and presentation and infrastructure the things tied to technology are external to the system and depend inwards not the other way [Music] around an interesting thing to note about clean architecture that is the main misconception I've find uh in is looking at this entity's green circle right at the center of the original diagram from Uncle Bob it's annotated saying that it has Enterprise business rules and then the application layer or use cases in this case as application business rules now there's many ways to interpret this but a nice way that I found to settle them is that the domain layer or entities there you can put logic in there as long as it doesn't know or it's persistence or externally unaware so in the application we might have interfaces or ports for external systems like a database or another web API that's great in the application layer but if you can do logic that's unaware of something external then i' put that in the domain so think of a game state if there's a certain condition then we need to you know set it as game over update some points things like that you can put in the domain so that's a nice uh little interesting point from the diagram now you'll notice that they're fairly similar but just different terms so that's clean architecture in a quick nutshell there's pros to it right there's lots of abstraction we've ripped out the infrastructure from the bottom of the system to the external system uh and that adds a high amount of abstraction now it's resilient to technology changes this is the key benefit of that whole change if you change your infrastructure your whole system isn't aware of that and it just should magically work now there's the devil in the details that's the main point again for the same reason it's very testable because domain again there's nothing external in the domain so you don't need to mock any testing for unit tests as an example and in the application layer if you have abstractions there you can mock the abstractions and it will work it's very explicit in that modularity now it's not influenced by in the external because again infrastructure is on the external of the system now there's consistent velocity so the other architectures we talked about has kind of that inertia curve for this I think it's a little bit more linear where it just gradually increases over time because of the abstraction it's a bit easier to work on by one or two teams uh but there's other scaling problems you might want a module or monolith for more teams to have more explicit boundaries between what team owns what and what concerns you might uh you know step on each other's toes for so there's cons to it though there's a higher barrier to entry so there's a lot of theory around it we only brushed on the surface layer of clean architecture but because of that you need a lot of training to understand clean architecture and a lot of projects make some pros and cons and have a tradeoff and decisions like that and Implement that in a code base now adhering to that in a consistent manner requires a quite disciplined team to utilize it well and gain the benefits that you know we're paying down with the abstraction and Dev time now there is a slower development time overall like I talked about there is that higher barrier to entry to start but it is consistent so if you've got a large complex product that's going to last a long time clean architecture probably will be pretty good now similar to that there's lots of cod to write a Syle feature the common complaint I hear is hey I'm building this you know simple crud endpoint that reads A Todo item from the database but I have to touch four projects or potentially eight projects if I'm writing tests and that's crazy now that might be a piece where you go and think well is my app really simple and in that way maybe I just use minimal end points and go end tier architecture or just a spaghetti architecture so so you know the symptom of the pain you're feeling might mean you've applied the wrong architecture uh or if there is that complex system then the lots of code to write the simple feature in this case it's complex and it might be worth it all right with that context let's jump into vertical slices so of course to talk about vertical slices let's talk about clean architecture right away so what happens in a request or use case when you hit a clean AR endpoint so for this example I'm looking at CR examples on two entities now you'll notice they all kind of align in those horizontal lines so there's some presentation logic so I always want to have an endpoint for each of these then application for this so there might be some service around it or validation things like that domain so these might all talk to the same twoo entity and eventually some sort of database operation now when I draw lines across this this is why clean architecture you might hear it as layer architecture the way it's written in code is from the technical concern so these four layers now again this problem of having your CDs scattered against projects really gets shown when you have a large curd base with tons of features there's lots of scrolling because you know you've got a scroll between 100 features folders replicated in all of those layers now that can be quite painful before I jump forwards I want to introduce a principle so this is called the proximity principle now any principle you don't need to apply everywhere but this is what I find as the core of vertical slices so code that is changed together should live together now what does this mean well instead of having these files sharded across many projects if it's all related to the same use case or use a story of you know as a user user I want to achieve X so in the 2o case let's say as a user I want to Mark a 2do item as done everything that is code related to achieve that should be in the same folder and isolated so how would we restructure this in a vertical slice manner well same crud example if we look at it with the ver uh the clean architecture layers but instead put a folder on top so create tudu as a feature folder read and so on and so forth and putting the lines vertically this time hence the name right we layered architecture or horizontally sliced it now we're vertically slicing it okay but what does that look like so in a web API this might look like one ASP net core host application and in the same too example you might have four folders each with three bits in it so we've got our same presentation logic at the top some business logic and some data access logic so one way to implement your feature folder could be to have manyi ners in terms of the concept of what's going on uh to eventually hit the database now in a vertical slice you can go and do anything in there right so it's an completely isolated folder you could write a single line uh single file uh big function that does way too much or you could put a whole clean architecture uh for project for onefold you know you can do anything but there's got to be some Middle Ground again remember we talked about pros and cons there's a trade-off so with VSA we talked about some pros right there's little to no abstraction because you just put a folder and do something in there it's up to you what you do in that fold there's a low barrier to entry for that same reason any technology change you want to make you can start to migrate each feature folder with no impact on the other features so that's pretty cool now the test ability can be per feature again what you do within the feature folder is a bit problematic because it's undefined and we'll talk about that in a second now it's easy to work on by many teams there's two parts of vertical slices there's shared code that all of the features touch and then there's the slices that have no impact on other features so if you're working within a feature you don't have to worry about impacting another team or another product within the same code base which is pretty awesome and because of that right I can deploy and go to sleep and sleep well now there's some cons as well right in any app there's not completely isolated features if I make a change to a twoo item maybe it needs to send a notification or it needs to trigger reporting update so there's always going to be features that communicate side by side so we need to be very explicit in figuring out what messaging we need so you know a mediator pattern or a service bus things like that you need to apply and that has a complexity cost but it does have the benefit of being very explicit in side effects of code it is also hard to choose what is shared code versus feature code now shared code has that wider impact of being very high risk and feature code obviously could fall into the point where you're replicating curd now there's pros and cons again and that's something to think about each feature can be written in a different way when you're uh you know say you've got two teams different levels of knowledge different opinions if you're let loose you might use one opinion and then someone else might use another opinion and as a new developer on boarding jumping between folders you're basically looking at completely different code bases and that's pretty problematic we as developers we're still human and cognitive load and things like that are still very important to consider in code all right that's interesting so we've talked about VSA but there's still that black box of how do we do a actual slice in a maintainable manner that's traded off well so not only is the demo kind of showing that it's quick to develop it solves the other pain of potential inconsistencies and it not being clear how you do aord them so let's jump into the demo now for sake of time I've run the terminal commands ahead of time and I'll jump over to the code in a sec so to initialize a project let's just make a new project directory CD into it and then using the net new templating engine I've prepared this little template for a VSA application now this will create a ASP net core. net8 of course project and we'll jump into that in a second and if you run the start commands it'll open up in your ID of choice now let me just change my screen share so that it goes to the ID apologies uh I I'd uh lost my audio so I didn't hear you call but yeah there we go awesome awesome just in case yeah I moved it over awesome so this is the project created with the net new template now there's a few things to look at in here there's a test folder and a single source project so immediately you might be thinking this is uh you know a monolith but once you jump in there's two distinct entry points within the project there's the big high-risk common code which every feature uses and the reduced risk calculated scope feature folders now within this template there's just a DB context using EF core and shared DB sets and then a common I Ino interface just to wire up uh the feature folders to minimal endpoints in the host now the interesting point is in here so we can use uh item templates so the command I just showed created the whole solution but using the same templ templating engine you can create feature folders as a group random individual files collections of files was a consistent manner you can create the same structure of feature among any project so in this example it comes with too and in here we've calculated some risk so there's shared code among this feature and its actions so there's a shared 2do entity I don't want to be having four or more replicas of a domain entity for the example another way to reduce risk in this uh template is our DB context is in common so that's shared and I don't like having shared code so it's one layer of abstraction into the feature folder using a repository to wrap around it now there's some endpoint codes here just using minimal apis and it's not too important exactly what we do in this template right there's some decisions made so we wire it up using the interface method and pass it to a Handler now this just uses Minal apis and it's pretty cool to see it in a non lamda method in the program.cs you can actually just use a normal method signature uh and inject so a request entity is bound correctly injecting the repository and a cancellation token just wired up fine now in this slice we can do some logic so this is orchestrating some domain or uh you know domain log IC then an interface so we're doing application orchestration logic and then some presentation logic now again it's not too important what I choose in this case the cool thing with the net new templ engine is say you've got an existing code base with decisions like this made so if you pick clean architecture or vertical slices maybe you've got an existing code base if you make some decisions you can create a net new template with that structure and enforce the the consistency across the code base so it's super important for vertical slices but still cool for other structures so this is one opinionated uh choice of vertical slices uh where you just have an endpoint and request response objects now to show it is using the uh you latest. net8 with the of core Swagger and some help methods so let's just quickly demo now I moved it over from uh the other desktop due to our te issues let me drag it over you can hit a you know get and in this case there's nothing if I post some text using that same yop endpoint and create something execute it and then get again we can see we've got a new entity here that's pretty cool so let me jump back to the slides that concludes the demo of vertical slices and how the net new templates can solve the major problem of inconsistency among a slice in vertical slice architecture so we've talked about a few architectures in this talk but which uh architecture should I use for my project so there's a few things to consider right how many developers are on my team how long will the project last how complex is the problem I'm solving or the new uh product I'm creating now if there's not too many developers maybe a monolith or an enter app is fine if I'm building it in one day and it will run in production for a long time without me touching it maybe a monolith is fine or a spaghetti architecture because is the abstraction cost worth the dev time devs are very expensive right is the business domain very complicated uh whereas the actual systems isn't complicated in that case maybe it's a domain driven design Centric uh clean architecture approach do I want very distinct knowledge of side effects and easier barrier to entry in terms of what codes I need to change maybe vertical slices are the choice there so obviously in the consultant fashion the talk will end in a it depends right develop as a human you need to think about your team the skill sets there how long and how many developers are on the team so in summary we talked about spaghetti spaghetti transforming into ntier ntier moving that data access layer out to the top that's really the key part of clean architecture to gain testability and resilience to change vertical slices kind of flipping the clean architecture on its side changing the code abstraction from technical concerns into business and use case concerns and then finally how you can get up and running with VSA quickly as well as solving the problem of potential inconsistency so that's my talk thanks everyone very much thanks that was really good I I really like the um the way you kind of broke down the different architectures that we have and um and how you can apply them to the different approaches um I know we had a few technical issues but like I said before that's how we know that we're doing a live stream is that uh you get to see the bugs and everything as they go out um I did have one uh one question for you is that the template that you showed us um is that a template that you've published that we could download and start using for projects ourselves or was it more just some patterns you're laying out yep uh that template is on GitHub so you can look at it on my GitHub on GitHub honer uh it's up there you can install it with the readme and you know make PRS and and you know Fork it and make your own decisions so you can definitely just uh look at the readme give it a star if you found it interesting and useful but yes it's definitely the public on GitHub like I said on the intro slide I love open source so I don't want to have that dissonance right where it's closed Source in My Demo yeah for sure um and as someone who's a former consultant themselves I loved how you just finishing like the answer is it depends and and anyone that's out there watching that's that's done Consulting work will be just like yep that's that's exactly how it plays out isn't it it's it just it's going to be whatever's right for you and I I think the more that we talk about and look at the different ways that we can use things the better informed we are to make the right decisions for what we're actually going to be doing 100% it's just a you know another tool in the tool box right to make the right decision you need to be at least aware of the different things out there and you know know where to deeper and you know what to pick in what case yeah exactly well thanks for joining us um at netc this year uh it was a great session and um we look forward to hopefully seeing you back next year for sure thank you

Channel: dotnet

Views: 18,263

Keywords: .NET

Id: T-EwN9UqRwE

Length: 27min 17sec (1637 seconds)

Published: Fri Nov 17 2023