Vertical Slice Architecture: How Does it Compare to Clean Architecture

foreign [Music] I love running this company I love running it because of the people I deal with it's such a great team of people from a career perspective it's the best move I ever did I'm enjoying the work I'm currently on a project I'm booked for another project soon giving me the opportunity to work with lots of different types of technology and explore some stuff that maybe only dabbled in at University or before ssw is a company that makes enterprise software Solutions and that's what we do we build software for clients on demand we build bespoke Solutions using the latest technology and the latest best practices I've been involved in the development of some mining software being involved in the development of software for a legal firm and everything in between there even in just under two years I've been working across so many different projects [Music] as we work into and I always look forward to coming to work so since I've been working here I've really been pushed and that's what I wanted you come to a place where you're working with a team of just absolute weapons we've got the best in the business here and that's an exciting place to be the guys are very passionate about doing things right the first time we share our best practices with the community and with our clients and with others using conferences we speak at events and also we have the ssw rules which is a huge Archive of the best way to do everything the management here is totally approachable so if you have a better way of doing it or you know of a better method then everything is up for discussion as an example say authentication so a lot of the guys are building authentication into their apps and they've been through many different ways of doing that so generally what ends up happening or coming from that is a discussion around what's the best way of doing it and we come to a decision based on industry best practice as well as our own experiences on what the best method and approach is and that then turns into a rule that we have on our rules.ssw.com.edu website [Music] what really defines this company and make it work is the fact that we have people that are able to share their knowledge and solve complex problems together it's it's a wide variety of different clients different structures different sizes different Industries and different Technologies as well the world we live in now is just so many light years above the world that we were working with even five years ago we get into lots of topics deeply and it's fascinating how it all works and why it works you know we get paid to make fancy jigsaw puzzles [Music] software is is a unique opportunity to be creative and Technical at the same time it gives you the opportunity to solve problems it gives you the opportunity to exercise and flex your mental muscles by solving problems and figuring things out while also being creative you can feel that energy when you come into the office there's a really good vibe and connection between everybody who works together here it's really collaborative and we even have the tools for for doing that collaboration now as well through Microsoft teams we always try and team up in pairs where possible for client work um two heads are always better than one I believe being a developer a good developer is writing good quality code but being a great consultant which we are this is W is half half between technical skills and communication that's what makes us different on the market that's what gives us our Edge because we're capable of not only doing great work in terms of you know technical skills but also bringing value and bringing all Insight based on our experience saying oh to solve this problem I would recommend you going that way or this way and bringing that value that strategic value to your client and being able to phrase it not only having it in your head but phrasing it to give them options [Music] and we make sure that people are communicating internally with each other in a way that is professional and succinct and we make sure that that's the way that we communicate with our customers as well and I want to show you a few ways that make email a more useful people that want to improve their communication through public speaking can do that through the conferences that we're involved in they can do it through ssw TV you might actually not need to go native guys have a lot of videos that kind of help get your face out there to get your name out there we also have a really good social media presence we have a great marketing team that takes care of that we are client facing all the time there's no way to work at SW industry behind the desk and not talk to anyone any you know every day you have to communicate so that brings communication as a core skill of what you've become and some people develop it a way further like by you know doing public speaking we have awesome speakers uh I think you know NDC videos prove that we have awesome uh you know Tech tips and and even conferences given by ssw people I think we had like six or seven this year so that's pretty huge [Music] one of the exciting things about working here is we're always on the bleeding edge of Technology we're always trying to reach out to those new projects what are other people doing what's the next best thing I think Adam being a Microsoft Regional director really gives us a bit of an edge in that regard as well because he usually knows what's in the pipeline before other people do we've had many younger guys come through ssw and in a few short years they've become absolutely amazing developers you can have guys with just a few years of experience and they're building software that's affecting tens of thousands of users with some guidance of the software Architects it just works like it's amazing you build something and you test it that you can enter an order and then all of a sudden you can enter thousands of orders like in seconds it's just incredible we couldn't do that a few years ago we have a couple of different ways that we socialize um every lunchtime we're killing each other in board games which is always good it's interesting because those games you know are about psychology that's very interesting you'll learn a lot about people [Music] the most exciting thing that we tell our company Retreats we go away for a weekend after doing a brainstorming session on the Friday we all work together as a group and work out you know problems for the company itself we always try and keep the activities a little bit different to make it a bit of fun it's just a great weekend all around [Music] people that come to work here want to be at that level of globally recognized expertise that some of the best guys at ssw are at and even if you're not at that stage now I think that a lot of people that come to work here are inspired by that a lot of clients come to us with maybe a general idea of what they want and you know you can use your expertise and past experience to really inform their decisions and make sure that they're developing the best possible product I really enjoy that part of it I think that would be very satisfying for anyone who's been working on maintaining an old piece of software or maintaining an old system if they could come and maybe work on some new Green Fields projects and potentially you know influence the way that product comes out at the other end you can come up with cool designs you can come up with new Solutions you can come up with elegant ways of solving problems that haven't really been done before and plus you get to build something and often the projects that we're engaged with you get to build something that's going to make a difference people want more stuff automated they want richer interfaces they want bot interfaces the architecture keeps expanding the knowledge of azure keeps growing like I'm still learning I'm still trying to get better I'm still trying to make Solutions quicker more maintainable cheaper and if there's a long way to go [Music] [Music] foreign [Music] [Music] thank you [Music] this is my red shell [Music] s [Music] thank you [Music] [Music] foreign [Music] [Applause] [Music] [Music] [Applause] [Music] yeah [Music] thank you very much for coming in guys I hope he's all enjoyed your rides today and I hope we see you all again guys [Music] [Music] [Music] thank you [Music] [Applause] foreign foreign [Music] thank you [Music] thank you [Music] [Music] [Music] [Applause] [Music] [Applause] [Music] thank you [Applause] [Music] [Applause] [Music] [Music] [Applause] [Music] Microsoft announces new co-pilot copyright commitments visual studio for Mac is retiring and Bun 1.0 has arrived all this and more I'm Adam kogan let's jump into the ssw tech news [Music] [Applause] [Music] g'day I'm Adam kogan and this is the tech news for September 2023 and what do we have well well I'll tell you first we have a great session on tonight it is a vertical slice architecture so let's go and have a look at this this is being done by Luke Parker and he's talking about vehicle slice architecture and comparing it to clean architecture this should be a really good session it's super important super valuable it underpins uh almost all the dotnet projects we do at ssw there's a lot of talk about how to do clean architecture right whether it should be separated down the New Vertical slice architecture route so that'll be a really fascinating talk I will also tell you a bit of news on our home page we now have a GPT powered assistant so instead of the old one where we had to kind of program every type of conversation it's now as smart as chat gbt and I can say can you do an angular project let's see if it can handle a spelling mistake absolutely doesn't care about spelling mistakes it can help you or book in the right thing if I say can you do woodworking classes and look how fast look how clear it is with things that can't do you know I'm sorry for the confusion we don't do that type of stuff uh so it's really smart and awesome now a few months ago I blogged how I did a talk on using GPT and open Ai and how to do that you can watch the talk and I explain how to do that but Microsoft have released something which is pretty cool it's called demystifying retrieval augmented generation with.net and basically what it's saying is that they have the ability to build a cool chat GPT like engine and they simplify all the embeddings and the vector databases so this is definitely worth checking out what's some other news we have well here's the big news we've all been wanting to use chat GPT and co-pilots and all this and and use it for code in our projects if you're using copilot Microsoft have announced that they are guaranteeing uh that you can use that you can take the code without worrying whether you're violating any copyright stuff they will deal with this I can tell you I think a software company our insurance company sent us a questions to answer wanting to know if any of the code we generate for customers comes from you know any AI Services because they're frightened of that and they don't want that to happen and uh but they did have an exception that if it's coming from Copart business that's fine so that's worth uh understanding now uh here is some news that took me by surprise Microsoft have visual studio for Mac it's been used for a long time it's really it should be probably called uh visual studio for xamarin because it was helping with mobile projects and Maui developers have been using this and been happy Microsoft have said no off this and on to vs code vs code can pretty much do it all it has a few extensions which are very new so it's unusual that they'd push so early and so hard but we have a year to get off this um I guess the you know some Maori developers are going to say hey it's not feature parody we're missing hot reload and a few bits like that so I can't imagine everyone's going to be happy with this um but I guess uh they're really wanting to it probably made some internal decision that they're not going to keep adding to this so they want people to start understanding they're moving people so that's happened next one this is an interesting One external rest endpoint invocation now what you might notice is it's coming from the SQL Server team see there now with SQL Server if you ever wanted it to do some c-sharp code you can call a series CLR extension but that was turned off on most on-premise SQL servers because it has security concerns it can do anything so what they've done is this talks about how they've added a system stored procedure and that system stored procedure can call a HTTP endpoint not just anyone they've actually kind of whitelisted it to a series here so for example if you want to call a power bi endpoint you can do that from a stored procedure uh you can actually call one of your own as long as it's hosted here on azure so that's interesting and that's cool and I'm glad they've done that there certainly are many use cases because it's new and we hadn't really been thinking about um doing this triggers are a little bit hidden uh there's going to be plenty of times you generally don't want to do this but uh for other cases this might be really interesting I've always loved triggers ever since I learned about them a long time ago but then I found the managing of them tricky because people forgot they were there and they'd get really confused what was happening next piece of news bun 1.0 whoa what is this well I tell you what it's a cool name that's for sure if you are using JavaScript and typescript a lot and you're building full stack locations you're gonna want to look at this 1.0 release people develop a lot on node.js and this is kind of the new node.js it is a lot faster as you can see from five times faster here it's also a bundler it's also a package major I'm sure people are going to come up with some fun puns on this fun time you know because it's like a run time uh what's the best way to learn this in you know just a couple of minutes I would always say a Fire Ship this guy's awesome well but as the name applies bun is also a bundler the bun build command will take all your source files and then combine them into a single output that can be used in a browser yeah it's just uh yeah he's awesome at teaching you things quickly uh look at look remember when we used to think webpack was fast look how much faster this is I like that is crazy you know way faster all right now next piece of news b0. Dev now talk about unusual names that's unique v0.deb now how does this thing work well you know how we can use say mid G to create images I I like if I go back here you know this this talk I did uh I'll just quickly go to this that cool image here it was done in mid-journey so and I'm not a person that can use Photoshop at all so uh now with this V zero thing a product owner with no front-end skills can start doing things so I'll just I'll go up to the beginning here just to get a bit of an idea just to show you the story so they can they've got this grid and they say change the download drop down into a button instead with a relevant icon too make the category tags with a less rounded Corner look at that natural language will change this what's the next thing for the three dots drop down turn that into a three dots drop down menu with the following options edit share delete you know use proper icons for them as well and like you can see change the three dots pop over menu this is incredible that you can go through and make your own UI by typing I've never seen anything like this and I just even using chat gbt uh a lot of times every single day of my life I was astounded when I saw this just a tool like this is just incredible and if you want to know more about it there is this 11 minute video by uh Theo it's a great video we'll take you through the whole thing the the connection between Chachi BT and front end code Generation Well um really surprise you next piece of news power toys I don't know how many people have power toys installed we used to always do it but there is a little bit of news here so you know you have a big screen like this and you only want to do this bit where the red box is you can turn that into its own window focused on that area so for example you have the whole window here you then select the section you want see the red box and say I want that and that becomes your window for recording videos or presenting uh something in a Sprint review it makes your screen very clean and if you want to put that in perspective here's the same feature crop and lock and you can see that with the other power toys there's a lot of power toys there this is uh very useful next piece of news we have to have a mention of Elon I don't think we've had uh news for some years now without Elon but he he's uh making a very large supercomputer called Dojo it is for all their autonomous driving it is pretty incredible all this is uh powered by nvidious they're making a lot of money uh the the amount of Tesla compute is extraordinary unbelievable alrighty now we like to end with some fun I don't know if you'll call this fun but there was some news from new Unity is the best platform to develop games they came up with a great new pricing model and what was the pricing model well we're just you can have a bit of a read what the pricing model was but it was essentially uh under unity's new approach developers utilizing the free tier of unity's development services will be required to pay you need 20 cents per installation doesn't matter if you sell it or not it's per installation yeah and I think uh or Unity developers were very happy with this announcement well that's what management thought and they were obviously surprised when the community were unhappy and you can imagine what went on on Twitter well there was a new announcement and unity uh did some blog posts explaining that it was all a misunderstanding they were reversing it their CEO made a little mistake it sounds like he's leaving and they say we apologize for the con confusion about that uh runtime fee policy we announced on Tuesday um and then they come back and they say hey we have a new tentative plan tentative because we've lost our guts Unity will be limiting it to four percent of the game's Revenue but only for successful games that get over a million dollars okay and they're all probably internally saying oh this is so unfair Apple can charge 30 of every dollar that anyone makes that's the story and uh now the community will be all upset with unity forever even if they ask for a dollar that's this month's news if you have more news or I've missed something or you disagree throw it down there in the comments we all love to learn we have this and a whole lot of other videos on ssw TV grab them learn tell us what you're enjoying and what you're not enjoying uh and I will see you in the next one this is Adam again signing off versus WTV [Applause] [Music] oh all right everyone welcome to the Brisbane full stack user group tonight I'm pretty excited to be talking about vertical slice architecture as well as clean architecture and diving in Fairly deep into both kind of showing the story of why you might choose one or the other kind of you know the benefits you can get as well as how you can get up and running with either or so without uh further Ado let's Dive Right In it's a little bit about me I'm a ssw software engineer too here at ssw like I said I'm an open source developer so I love to put projects I build just public there on GitHub so anyone can see it steal the code use it whatever all good all good with me uh I love anything related to you know software architecture so you know if it's a good idea a bad idea something that's contentious or you know widely accepted or being Keen to you know stay up to date uh and you know have a think about it also just newly addicted to the gym so that's fun always eating and then you can find me on uh Twitter GitHub uh all my blogs down there I guess it's called X now right not Twitter so maybe that logo needs changing uh ssw has a little Rewards app so every event we run like this user group you can download the app and uh scan a QR code at the end and get some points so just for free you know over time you can earn like a digital thermos or a uh you know Smart Watch so scan that if you're interested so tonight like I said we're going to go through you know what is clean architecture so some of the basics so not a super in-depth course but enough to kind of go above just maybe the four layers if you know that much you know a little bit deeper and and why we got there as well as a demo so just how you get up and running uh you know everyone's done the boilerplate for you so I'll show you how it can get up and running really quickly pulling on from that we'll do vertical slice architecture so similar to the ca we'll talk about you know how did we get here what are the benefits you know uh you know why might you pick it and then a little demo so how you can get up and running with vertical slice architecture really quickly and then right at the end a little hidden nugget I didn't advertise so if you've who's heard of a modular monolith before quick hands up yeah it was fairly confident with it or they just know it exists you know hands over if you're confident you could you know do it yeah so right at the end we'll kind of talk about the modular monolith a little bit which is basically how you can gain the benefit of can VSA kind of together so that'll be exciting to talk about so let's jump into it what is clean architecture and why so right at the start of the story right what happens when you have no architecture what might your software look like gone we won't expose them but yes we had a chat before the session about some horror stories of what an architecture might look like so you know imagine you know four figures of projects you know circularly referencing each other something like that just as an example out of thin air uh so let's assume maybe you've got a client making a request and maybe they're doing some you know presentation logic maybe some business logic maybe some like system or data access that seems pretty perfect world and eventually it might hit the database but that inner part is kind of a question mark right maybe that happens maybe that doesn't happen it probably over time transforms into spaghetti where you know you might start out with no architecture and have it somewhat clean but your on-board developers and it lives for 20 years and then everyone's got competing ideas some people do a hack here or there don't document you know why you may or may not do a thing why you did a hack raise a backlog item of you know fixing the hack you did you know no architecture no standards there you're probably going to end up with a little bit of spaghetti architecture you know in a project this might just look like one project where you just got everything together that's kind of a very simple example maybe you have thousands of randomly named things maybe no conventions people use dots of like you know the company or the project dots on it maybe you don't even have that maybe a random names who knows so it's a wild west out there with nothing so that's the pain right with no architecture who knows what you're gonna do it's going to be a big pain after a few months imagine you know 20 years so that's the monolith basically you know you're kind of just splatting stuff out uh there's basically little to no abstraction so you can think of that as a pro right it can reduce some friction so that is an upside for a use case it's quick to build early you can go from nothing to deploying it yeah because you're not spending time on abstractions so that is a benefit it is it does have potential for for performance so I'm saying potential I'm not saying your monolith is going to be super fast but if you have less abstractions there will be less CPU usage and stuff potentially you'll probably write worse code because of the worst structure but you know if you're writing some embedded code that's ahead of time compiled on a you know system where it's like that you know maybe you're not going to write like all this abstraction which is actually just you know resources you can't afford so that is a potential benefit the downside so the major one right you know you can probably just call it inertia you start off really quick you're deploying your writing code you might just be you know deploying it to a you know server or in your own network or just deploying it to the cloud really quickly but you know that becomes a debt that increases you know the amount of time to deliver I think that's the major downside if you don't have anything quite difficult for multiple teams at once right even one Dev over 20 years probably will you know result in a fairly spaghetti app imagine a whole team imagine Five Ten teams asking me pretty much a nightmare a technology change so thinking of a system that is trying to last a lifetime or a long time if you're changing your technology or a piece breaks if you've got this architecture where anything can impact anything a p a uh technology you're trying to change or something that breaks you don't really know the wide impact of a bug or the technology change probably will require you know changes throughout your whole code base uh and obviously that piece kind of makes it really hard to test to be tested so you know no architecture no structure it's very hard to uh keep stuff in a very testable way so modularity and testability are quite hand in hand Okay so we've got this pain let's think of some ideas to keep it testable maybe we'll rip out some of the technical pieces so let's picture basically the last graph we had but actually you know separate and make sure the structure uh separates those technical instance so a client might request into your API so we're just going to assume you know building an API you can architect you know software for any type of app but uh you know a lot of devs do Enterprise stuff and it's going to be an API so we'll just assume we're talking about apis we can apply it anywhere right so ripping out some technical concerns you might structure it with folders or projects or anything like that we'll dive into how you might implement it later but you know this is theoretical right so you might at the top you'll get a request in you might do some presentation logic so if you're on an API you might do some HTTP stuff you might have uh you know Json web API you might be using another protocol like grpc or you know anything like that protobuf if you're doing Game Dev maybe you're doing you know really quick two-way message whatever's in there right you could do that alone just how that interfaces and then separate the piece where you're doing the logic so once you're in the system Splat everything in there and then below that is data access so if you're doing your fancy logic of what should happen given data and you know use cases things like that and then talk to the database so this would look like you know maybe three projects in uh you know.net app maybe you have your presentation layout which is you know asp.net core and that could reference the business logic piece where uh probably the most overused term in at least every project I see as Services everyone's like oh this code does something it's a service let's get away from Services guys think about it uh so yeah this is probably going to be the bulk of this card base I think uh and then the business logic references data access which might be repositories it might be something else you know maybe there's a third-party API or other systems all the interfacing uh or reports and adapters there's tons of different terms could be in there so this one is called end tier right in this case we had three tiers we had you know presentation business logic and data access those are our three twos and it's very kind of one directional so one kind of key thing to note is data access is at the bottom so all paths kind of depend on the data access uh so that's a you know interesting thing we'll look at in the pros and cons so it is fairly intuitive uh the abstraction's not you know painful right you don't have to build all these uh we'll use Java as the example right everyone knows the joke of like you'll have a factory manager who loves you know 20 different patterns to achieve a simple thing coming into you've just kind of ripped out a few of the bits you've kind of made it obvious where things encouraged to go to some degree it is fairly quick to build as well right you could just write the projects and have controllers here services in this project and repository or ef4 on the bottom and that's you know not really you know intrusive to the the dev experience it has some improved testability but we'll talk about it in the cons uh you know why that structure doesn't work again I think the inertia will increase not as bad as the monolith but I think as you scale if it is going to be a large app or a long running app that's you know undergoing depth time I think the end here you know as you get complex features as features kind of talk to each other and there's some intermingling that inertia will kind of kick in a little bit again it's difficult for multiple teams so as you know the the intermingling might not be as chaotic as the no architecture you still have the ability to you know intertwine features and have side effects that aren't too documented so because of that multiple teams you have like the IP knowledge of each team and their code base living with each team for the most part and that gets fairly hard for each team to coordinate in one code base that's just basic into it to kind of make sure there's no weird things going on so you feel some pain there and it's very similar so the technology changes like we talked about with the monolith is going to impact the whole system uh so let's try this one zoom out the data access layer is right at the bottom so if you change this every bit of code is going to change your service is probably a you know hard coupled to DF core or a specific repository you've built or something like that so that's that's definitely can be a downside how about we get some clarity between kind of the business use so logic and you know kind of thinking in the DDD land of you know what do we actually want to do let's think about our domain uh and then separate the technical concerns so you know the important logic versus the you know what we need to actually make it happen in code what if we split those two up or we can kind of switch up this data access so remember the enter data access was at the bottom if we pull it out from the bottom and put it on top we get the structure where a domain and application so for now I'll dive into what those two are later but think of this as your business logic together these can make business logic you now have no dependencies external in that business logic layer so testability you can mock out things really easily you can change out what it actually does at the end of the day you know whether it's a database or third-party service and still kind of have your tests ring true so this is pretty good uh a good step anything that's a technical concern is kind of removed and the happy path is you know presentation and infrastructure are both kind of the peak you know externals of your system and then the you know bulk logic is in that bottom layer so what might this look like in a you know project structure well we bring out the clean architecture onion so this is basically just another way to show the the tree where we moved infrastructure out to the top at the bottom we've got the domain and application there and they're both gray kind of signaling that that's the core of the app and then right on the outside presentation and infrastructure are equally removed and the key thing to note is that the arrows point inwards so if you haven't really like dove into clean architecture the arrows are very very um explicit and it is just showing like hey we are intentionally saying infrastructures right outside and it depends on the system not the system depending on things external so that's very important now we're seeing uh this variant of the clean architecture onion buses you know this one where it's got our four layers who's more familiar with this one hands up yeah who's more familiar with this one ends up yeah a bit about half and off so this one is kind of more the original from Uncle Bob and an interesting thing to know you know if you haven't uh gone into the theory of clean architecture too much the you know bottom most layer you could call it domain or entities a lot of people will make it really uh simple and the term you'll hear online if you know a bit more they'll call it an anemic domain and that basically means you'll just put your models which are they're basically copying the table structure of your database and just putting that in the domain or the entities layer but if you look over here Enterprise business rules or you know business rules that sounds like logic so that's interesting use cases the layer around it so we can kind of think of that as the application from the other slide that also says this one's application business rules okay so our domain and application can have rules like what's the difference basically the entities or the the core layer is unaware of anything external so in the graph back here application has interfaces to know that there's something external it doesn't implement it but it knows that there's something whereas the entities layer here just has little models they're kind of pure functions they act on um the entities themselves and then the use cases you can think of that as like a aggregator or an orchestrator where it pulls the entities or the Enterprise business rules uh and then you know uh just cause a few things and chains with things external now Uncle Bob's clean architecture he's not saying that you have to do it in any specific way everyone kind of has their own interpretation uh and this is you know our an interpretation my own interpretation and everyone can kind of take this graph their own way so the most common one is you know you might have seen the popular clean architecture templates with those four layers in that way and it's just one of the ways to do it uh and then the the outer rings I won't go into that too much but I thought that's interesting to kind of think about your domain layer and that it can be more than just entities so yeah that's kind of the two compared so clean architecture it's pretty good for those larger systems because it has the abstraction it's resilient to the technology changes right the infrastructure instead of it being right at the bottom where everything depends on whether you're touring a SQL server or whatever it's kind of removed as it's isolated piece so that's pretty good where if it lasts 20 years and you pick some really bleeding edge database or technology and it's been you know huge security holes or you want to move something else you know any big change is going to suck we'll get that you know out on the table but at least you don't have to be you know changing every bit of code you don't know what's going on it's kind of scoped you know what you're getting into if you have a change like that it's very testable from that structure if you have a rich domain which is kind of what you call the domain where you're putting logic in there you can test with essentially no mocking right in unit tests you might have mock if you've seen uh mrq or n substitute usually mock stuff if you have a rich domain you don't need any mocking you're just kind of creating simple uh you know classes data and then running methods from the domain and just asserting State and that's very easy to do so if you load a lot of logic into the domain you can get some pretty um cool tests and then the application as well if it if it's acting as an orchestrator you mock a few things you've already tested your domain logic and you're just testing that kind of orchestration piece so that's a pretty cool thing uh if you don't do clean architecture well you do lose out on some of these things so there are trade-offs uh you know there's a lot of abstraction to have that rich domain and just orchestration application piece but if you want the testability you know that's something to consider it's not influenced by anything external so the infrastructure or the data access is kind of a second thought if you want to build your clean architecture up thinking of domain first or application uh the inner layers first the way you store your data or the way you send an event or hit a service bus or something you don't care how it happens you just care that it does um so it's pretty cool to think in a way of just writing planes C sharp build some interfaces if you know it's not going to be within your system and then write those interfaces later maybe you build out all your logic just build a skeleton interface and right at the end you're like okay I need to write a row to four different tables from my one big domain model how do we have you know do this and we'll just write that one method and now it's wired up so it is pretty cool to work in that way now I think uh it's got consistent velocity right I think the the inertia is a little bit less where it's you know instead of those exponential curves to me the projects I've worked on you have a pretty high cost right at the beginning where it's just like you're setting up all these things it's you know not as quick if you've built your own personal projects with again no architecture but it is consistent so you know again if you're working on this all day with lots of people over a long time you know you can kind of have the same expectation within a few years of like you know these features aren't going to be scaling up crazy amounts um but it's definitely going to be increasing slowly uh any code base that gets larger as you know a cost Associated to it uh because of the separation and kind of abstractions and the testability it's easy to work on by you know a few teams at once so you know if you've got that good test coverage really utilizing the modularity of the inner layers you can have more confidence as you know maybe you're another team maybe you had to touch the other team's areas a little bit if they've got that test coverage and the tests are still passing you know you can kind of sleep easy at night not worrying like oh we're gonna have a big production bug in the morning and I'll have no idea what they're doing the whole team's on holidays you know on a cruise we're not going to be having a good time if something goes wrong like you've got a little bit more peace of mind and that's kind of important for sanity right so it does have the higher barrier to entry I think the major problem I see on the clean architecture projects is you know a failure to train or you know understand the theory behind it so you might go on a project and kind of understand the layers and what you put in there but every project has different pros and cons you know hacks trade-offs whatever so without kind of understanding the theory you might not understand why people made a certain trade-off what costs are they you know saving or you know paying down for what benefit what are they losing out on um and that can cause a lot of pain where people are butting heads you might have a purist that they want this perfect clean architecture and then you might have some people with trade-offs and then you know they're butting heads because competing concerns and then you're basically on the do anything architecture right if if it's slightly different opinions over time you know that'll add up so you know if people don't have their perfect architecture it's still better to be consistent I think in the long run where people are fairly close um but consistent so yeah that's definitely a barrier to entry uh but it does depend on the training and definitely discipline that's a big big important keyword if you're not disciplined with it you're going to slowly introduce these problems where maybe you're going to skip a few layers maybe you'll muddy some logic together with the external systems I think the major problem is in end here right we had everything leading down to data access you can get lazy with clean architecture and splat all this logic in your infrastructure layer so oh yeah I've got to talk to the database so okay I'm talking the database so but I need to do some logic so I'm already in the database layer sort of do the little bit of logic well you need some discipline to go hold on all I'm doing in the infrastructure layers I've got this thing I'm doing an external or the other way around and then I'll bring it back into the inner layers of my system looking at the onion you should basically be scared of these red layers you want to if you're in the red layer you'll go like hell no this is scary you want to get out and get right back into the application and domain as quickly as possible and that's kind of where the discipline lies where it's like hold on I'm spending way too long in infrastructure am I doing something here that you know could be in the core layers you know there's lots of other examples but I think that's the major one that you see in most code bases uh let's jump back so yeah obviously slower development time overall so because it does have the consistent velocity you've kind of got just that slower thing of building these in the right ways thinking about the layers is just a little bit more involved what's the code to write a simple feature I think you know without having done lots of time on clean architecture that's probably the common complaint it's like I have to write all this code in all these different places just to do a simple crud API like why do I have to do this if you are just building simple crowd apis do you need clean architecture like maybe it's a wrong wrong choice maybe you just need end here if it is really going to be prod maybe use one of those you know generator things or graphql or something like that if you're not really doing much logic you know if you don't need the benefits of clean architecture the cost is it worth it all right let's jump in into a demo so I'm going to show you how you can get up and running with uh asp.net core and clean architecture so let's see let's zoom in so what we have uh at ssw is a clean architecture template we've developed so it's very similar to the ones out there just with a few changes then you know random quality of life things so it'll be familiar if you've seen uh you know either our dialysis template or Jason's template on GitHub so let's create a new directory here so I'll just call it you know CA demo and then CD into it now we have a net new template we've seen the.net new template engine protocol right so if you haven't seen it before basically you know instead of copying like a code template or downloading a zip or anything like that it's kind of just a little you know search find and replace template that'll bring that code in from a nougat package or something like that and apply it to your project so let's say I'm calling this project CA dot demo if I use the.net new template of the sswca project it'll bring in this up and if I list what's here okay maybe it's a bit bigger let's run it again we've got a solution file here if I open it up in Rider we can take a look at what we've got see if it opens there you go let me just zoom in cool so within the template you've got a bunch of things but I'll kind of keep to just the architecture and the structure uh to keep it simple so we've got those four layers from the onion before web API here is the presentation so all it's got is features and within those features is just the endpoint logic so in a web API that's http all it's going to do is the HTTP logic so in this case it's you know saying on this route I'll send a request inwards and maybe some Swagger documentation so the Swagger docs that's coming out of the box and just saying hey when you send this request it'll respond with this data type uh with a nice name now uh who's used mediator as well quick pull yep so it uses mediator uh just kind of like most projects so it just sends that request inwards mediator is a nice way to kind of work with clean architecture it's got tons of benefits right but as a way to enforce clean architecture it's nice to separate your you know presentation logic to get into your application layer uh where the mediator commands and queries kind of stay within the application so uh there's other things in there right health checks exception filters but you know that's not too important for the architecture jumping on into the application like I said it's got those cqrs objects using mediator so commands and queries based on features within the feature uh you've got you know the command and like I said there's trade-offs so our template we decided to use EF core essentially within the application now that's infrastructure right well it's really painful to rip out your complex query logic and things like that so most projects using CA will kind of use the DB context within the application layout so this isn't purest CA but there's a few kind of trade-offs we've done to nicen it up a little bit so the first thing you'll see is we've got this with specification thing so this is a package by our Dallas so another big CA guy and essentially what it means is within your domain you can have query logic so in the templates very simple imagine you're spinning up a new web API project Microsoft has like the weather forecast thing right so it's got a simple to-do item in here but you can chain basically all your link queries in here you can do anything you know crazy that you want to do with your normal EF queries but this is in the domain so you're doing data access but abstracted away from the actual provider in your domain so it's a rich domain now we wanted a rich domain so we can test it well let's look at the Domain unit tests here you can test uh specifications as well I'm not certain if it's in this uh yeah it might not be in the template but because it doesn't rely on anything you can test this very easily and just execute it on a raw list and run the specification and get an output so that's pretty cool now there's the normal commands queries uh fluent validations things like that uh to get up and running now in the domain it's got slightly smarter entities so it's not full DDD but it's got starting to get some logic so object creation maybe some default State maybe a bit more focus on a you know Valley object Theory where you're like hey I want my entities to always be valid it's not applying all these rules but it's kind of hinting it there we're not you know enforcing all these you know really hardcore Concepts it's just kind of lightly pushing you in the pit of success where it's like have a think about this give it a go uh so yeah I want that onto that too much in the infrastructure it does all the EF core stuff so it you know throws all that scary uh you know column mapping and constraints in the infrastructure I won't dive into the domain events that's a topic for a whole other talk uh and you know whatever else you need there with seed data or migrations uh so that's that's kind of a Basics intro to the template there uh one cool thing is you can spin up a whole query using uh the templating engine so you don't actually need to create files and stuff for a feature you can kind of just run a command and say hey I want to be able to create a user I'll call it that based on an entity called Navy users and then maybe the namespace uh will allow Rider hopefully that doesn't break anything uh based on what do we call you know CA demo or something now I think I have to run it in the right folder so this might create them in a you know Wild West structure but I'm doing a live demo so who knows uh created successfully oh yeah I didn't scroll down there we go so yeah you're meant to run it in the actual application layout but you can kind of see the structure if I CD into commands here it's created a whole create user within that feature and then within create user it's got you know the command and a validator and linked up to an empty so a bunch of the boilerplate is used with that templating engine uh and even if you don't get anything away from this talk if you've got a big app where you've got similar structure within you know you're out that's somewhat consistent it's very quick to get this.net new templating built and running itself so if you find yourself writing very similar code you can create one of these templates yourself and just deploy it across your whole team and they can just kind of get sped up which is pretty cool all right so that's kind of the basics of the clean architecture template moving on to Vertical slice architecture so clean architecture what really happens when we do a request or a use case so a use case is kind of just like that business you know enabler like you're enabling something to happen thinking less of you know the code of just like hey I want to be able to achieve something so what happens when you do that you might have some UI whether it's uh you know physical you know win forms or something or a web API some way to talk to the system you might then go to a service or a command Handler or something like that we'll overview service again because you know everyone loves to use service maybe you talk to an entity and then maybe you talk to a database this is fairly similar for most crud operations right so there's some some similar themes there we've got presentation at the top right if we're thinking of the template or the project structure that would be a web API project application for those services or command handlers queries query handlers things like that your domain might be these entities so these all might be the same entity you might have a different entity who knows uh and then in the infrastructure you'll figure out how to actually save it to the database or query the database so yeah kind of everything talks through same layers in somewhat of the same structure now it doesn't have to be this way this is obviously this crud so in a larger app things could be you know doing lots of application jumping back and forth a few times who knows uh but for the you know sake of demonstration this is just a crowd operation I want to introduce the proximity principle what is it it's basically just saying hey code that changes together should live together now what does that mean well if I jump back to clean architecture the template let's say we have the to do feature so imagine I have 100 features within this code base and I need to I don't know add a new field to the Tudor uh yeah section of the app I have to jump into this web API project hunt down you know where is the 2D endpoint okay it's here okay it goes to a query where's that query somewhere over here dive in I was a command or a queer I don't remember you know jump in maybe it's create okay this talks down here okay what does this create thing do in the domain layer here okay it does something it raises this event what does this event do you dive into this Rabbit Hole where you're touching every single layer of bouncing you know quite often uh and that's that's pretty scary for a new developer as well like imagine you onboard someone you tell them a fairly simple feature but now they have to be touching kind of all across your code base uh now this principle isn't a hard and fast rule you should apply everywhere it's just another tool in the toolbox right maybe you want to have it left together maybe you want the technical concerns abstracted so what if we apply this principle to uh you know a code base so instead of having uh code separated by technical concern so whether it's the presentation bit or the infrastructure or logic let's kind of group it by what happens when I want to achieve something so I want to achieve creating an item in the system I want to read an item delete an item right now we can rip away clean architecture and what if we just put everything we need to create a tudo item within one folder what if I put everything to do get in one folder and so on and this is kind of the basic premise of the vertical slice architecture where instead of separating your concerns of The Code by technical concern it's separated kind of thinking of flipping at 90 degrees like the graph right instead of horizontal you're separating the concerns by feature or use case so what does that look like you might have the common web API right one point in you might have a feature to create a tudo item you might have some presentation logic and then business logic and data access within all these features and they might all talk to the same database now they also might not you might have microservices so they could be a form of vertical slices where each piece of functionality is its own individually hosted piece now is that a good idea maybe not it could be you could go super purist but we'll talk about a little bit later but you might just have the one API a bunch of folders and a bunch of files within that so you might have a file for your endpoint and then next to that you'll have a file for your business logic and next that file for direct access and again we'll look at that later so vertical slice architecture I'll do a demo later but basically it's good it's got little to no abstraction which is pretty cool low barrier to entry so again imagine that you know use case where you hired some new Dev maybe they're fresh they don't know too much about Dev work you can put them in the one folder and kind of they can go wild and they're not having to jump through this big structure they don't really understand now you know any onboarding process isn't going to be just hit the ground running it's still going to be a process to get up to speed but that's pretty cool to have everything within the same folder or area or some sort of grouping it's somewhat resilient to technology changes now this you know nuanced this right within a vertical slice you have complete control so if you're very purist well you can do absolutely anything within the vertical slice so if you imagine right back to the start of the talk with the monolith where anyone's doing whatever they want they're doing what they think is best now what if we apply that same thinking within each vertical slice you can have people basically creating a spaghetti architecture just calling it vertical slices because they're like well I can do anything in the slice so I'll create my spaghetti mess and therefore maybe it's not resilient because you have to change 400 different Technologies if you want to make a change so there is a Nuance to that now if you're architected in the right way it's resilient low level of testability like I said it depends how you do it but it can be per feature so maybe you've got tight deadlines for a few things maybe they're not hot pass maybe they're not Mission critical you've got budget concerns maybe you write your few features that you care about to be really accessible maybe you write other features to be you know pumped out really quick it's kind of up to up to you yeah because of that grouping of you know IP and kind of the business feature use case being grouped within the folder it is easy to work with on multiple teams because again if the team is working within folders they don't have to be worried that their folder somehow other people depend on their folder it's very kind of distinct in that you shouldn't just be working within that little slice and not going sideways feature changes have no impact on other features if you're architecting in the right way of course so you can sleep well at night you know I love to sleep right so this keeps me very happy I can deploy a change and not not be just up stressing having a nightmare that you know again I'm going to get a call at 2AM that something really bad happened so we didn't really talk about it but we looked at the simple product examples in a real app you're going to have features that impact other features now how do you do that in vertical slices well if you have that kind of bigger system that's more real world you do require that code where you're making it distinct that basically you're doing what microservices does on an infrastructure level where they're doing messaging over the network but you're doing messaging within the same app where it's like here's a contract I want this to happen you handle it so you have the boundary of saying please make this happen and then another slice can make it happen but that is overhead so you know that can get complex that can be done poorly you do need to put a little bit of effort into thinking of what those contracts are how those messages work uh but it can work pretty well and like I said if you write your feature in a different way every way uh you're gonna have pretty bad cognitive load switching between features because it's going to be like your onboarding off-boarding from projects you know however often you switch between peaches all right so we talked about you know a little bit of theory but how do I get up and running so let's say I've never seen it before but I want to try it out so let me jump back to the demos folder again a.net template so I've got one that I've made so you can start a new vertical slice architecture solution and then if I open rider for the sorry actually I should make a folder for it first let's call it North Wind and then CD into that and then create the new template the template you know automatically detects that folder so it's pretty cool to just call the solution the right file and then we can open that in Rider I should give it the solution extension though open it up and what have we got in here well we've got one project which is our app and within that project we've got a bunch of features and within the features uh kind of feature grouping you have your real features so bringing it back to simple crud I've made some trade-offs so some of the things to speed it up a bit some of the things slow it down a bit the things that speed it up is within the feature grouping we've kind of got a consistent Repository so if you're going really super purist in vertical slices let's take the create tudu as an example so ignore everything in the structure for now if I'm going really purist inside create tutor I need to do data access so maybe I need create Tudor repo to do data access somehow maybe I need a readme why is there a create tutor you know some business context on it maybe I'll actually create the UI so let's say I have a Blazer front end maybe you'll create the create tutor form as a component within this folder maybe you'll do something else uh maybe you have again maybe you have an entity for create tutor so not just one shared to do maybe you have an entity maybe within this entity you need migration so if you change that entity and you're deploying it maybe you need migrations maybe you're doing the migrations really poorly so I'm doing a really bad my bad SQL script maybe doing that in there we talked about uh making trade-offs and not documenting it so maybe you've heard of adrs which is a way to record those decisions and where they came about so maybe you're deciding per feature I want an entire ADR there where I've got every record of why I made a change and so on and so forth so this is kind of really out of showing the extreme of you can go really pure everything you need completely isolated for this but you know that's like I said extreme so I'm just going to delete that folder that's not going to be saved all those files painful the trade-off is you know you've got a repository shared within that grouping uh let's kill the second one and it's got you know an interface so like I said we want it to be somewhat uh resilient to those external systems changing so we'll use an interface I can switch this out later but we'll use the F core for now shared within the feature is the entity so tutor entity is used among all these four bits dependency injections so you can just add what you need within those features uh once now I'll talk about this at the end of the talk why this can be useful instead of just splatting all your dependency injection at once but it will come in handy later on now has anyone heard of fast endpoints before quick pull yeah so this template just uses fast endpoints it's a pretty cool library with some benefits but it's pretty new as well so later on we might just go minimal endpoints but it's pretty cool for uh you know a vertical slice application within an endpoint so this is using fast endpoints it takes in a request and an output so to update the entity I take in the entity itself now the vertical slice this method here says hey put on slash to do with an ID and it's unauthenticated well this is one bit you could think of it as a technical concern being split out a little bit it's not really enforced but because we're using the library we have that method forcing us there so it's kind of pushing you to keep some separation but you know you've got your HP logic and some logic right below so it's pretty cool to just jump in and change the route I can have a repository and then do some logic so in this case it's just you know doing update logic we won't dive into that and that's kind of the basics of a vertical slice app right you have a folder you can pick how hardcore what trade-offs you want to make same with clean architecture uh and and go from there so the template I can just demo they're working uh or run it up so fast end points has swagger as well so you just run it it'll all work magically with those endpoints within tutu you can get all of them right uh there's none there we can maybe post one and just create one oh I deleted it yeah because we never mind I deleted the entire posting because we it was too far gone so we can't create any entities but I promise it will work next time I won't delete the folder uh but it was good for effect so I'll live with my decision all right so that's that's the vertical size template we'll jump back so that's kind of how you can get set up quickly up and running right if you use the thing you can hit F5 right away without diving into the code and have endpoints working you can create a model and maybe with those item templates so I showed it in the clean architecture thing we can create a command or query this template will get those item templates soon where you just can create a feature and it'll do that shared repository shared entity and get you up and ready to go so yeah that's vertical slide side protection now the little Golden Nugget at the end how do I get the benefits at least some of them of vertical slices but hey I've already got this big code base with clean architecture already so what's the problem with clean architecture let's say you've got a little e-commerce app it's got a bunch of features maybe you have authentication and a bunch of features within that maybe you've got a cart and a bunch of things within that and so on so forth this is a small example right maybe there's only 20 groupings of features and you know a few things within those features uh as use cases now authentication is somewhat removed but what are some things that should be together like maybe products and cart is grouped but it is just alphabetically ordered so things that maybe are somewhat together get really sparse and then when you have that same feature format among the four layers in clean architecture you start scrolling quite a bit or relying on you know hotkeys to navigate and things like that so that can be a bit of a pain one step in the right direction maybe you'll just add another level of grouping among features so one thing you can use is area folders so let's just think of features with their use cases areas have features you can have many areas so maybe I have user experience as an area where the user is able to you know log in and reset the password but also view that profile and edit the things maybe there's a you know marketing team where to enable them they need you know to be able to get reviews look at them send out emails things like that or you know some sort of analytics and recommendations so this is pretty cool let's say you know maybe we have five teams maybe there's one team working on user experience maybe one team working on the shopping experience things like that a benefit you can have with the areas is if you use GitHub or any other kind of tool has this as well you can put code owners on the areas so jumping back on the features it's very hard to lock down kind of code review forcing someone to have you know the right person have the eyes over the amount of features uh code code owners on GitHub has a fairly small size limit so you know in theory yes you could fill it all up you'll hit the size limit and then you're done for if you put everything within an area folder you at least just link it up to the area and then put things within the area and it can scale a little bit better as well as helping teams just stay within their area folder you know for the most part obviously you're not forcing them within that but it just helps them have peace of mind that they're working within this feature so that's one step but modular model 3 into that right at the beginning it's pretty cool it's very involved so you know maybe it's not the right choice for a lot of apps but if you're really big maybe you have you know 100 teams lots of features yeah thousands of endpoints whatever maybe it's something to consider for the pros and cons clean architecture let's take one onion let's see our app has one little login what if we throw another onion so maybe this is like vertical slices but of a whole lap so maybe we've got like an onion another onion another onion maybe even like a little vertical slice piece Maybe now what if we have like a Gateway so think of like a reverse proxy or whatever you might want to call it so then you know the old days might be nginx or something like that what if we have a gateway and then these modules the Gateway just points these modules okay and then what if we call these modules something and then have a little piece to the side that's kind of cross-cutting that each module can touch now this is kind of like the 10 seconds of modular monolith now what does it actually mean it basically means each module here is completely isolated from the other modules except for the messaging piece so we talked about with vertical slices that you know in a real thing you know the marketing might need to fetch a user or some perhaps something about them or you know update something about them you know these modules will have to talk to each other so you know they're isolated but because usually you'll build it in a project structure you do enforce that boundary a lot easier and you have to use the messaging but because it's isolated you know uh that the changes you're making are bounded within that module and because you have the messaging to do module to module communication it's very distinct that hey I need to talk to this module I'm going to do this change whether it's updating state or dispatching something so maybe similar to mediator you're doing cqrs or it's very obvious whether I'm updating or fetching now the piece where it's kind of that middle ground between vertical slices and clean architecture is the modules of the vertical slice right instead of a wild west in uh you know the vertical slices here where you can do anything within a feature folder you have an entire clean architecture piece uh in the module now I'll show you a little bit more about that in a second but the shed kernel I haven't touched on that think of any shared bit of code that you needed within the modules so maybe you're doing DDD and you have the idea of an aggregate route or event sourcing or you know things like that that are going to be used among every module you put that in the shared kernel and each module can just look at that shade kernel maybe you also have kind of common infrastructure so if you're using EF core across everything you can put that in a shared kernel as an infrastructure project within that but again you should try and think of putting as much within a module as possible and you can also again girls wild or as you know tame as you like it's a trade-off you could not share any infrastructure code you could have a database per module you could share a database you could have an you know DB context per code base one database but a DB context per code base you could have a shared DB context it's kind of up to you to decide how much abstraction do I need how much isolation do I need what are the pros and cons that I can get from this so let's jump into a real example now I didn't build this one but it's open source so let's kind of take a look at how it works uh now let me pull it up where are we it seems to be lost let me go to the links ignore me jump into the uh links here so the demo is this one now I'll jump back okay no you're not completely good I'm gonna go to the code on this one cool right this is a little e-commerce up so similar to the example we've been looking at tonight built by a guy or consortia I won't even attempt to pronounce his name but it's all in 2015 so definitely check it out later we're not going to dive into the specifics of how modular monolith works or anything like that but we're just going to kind of pinch you at it so you can look at it later on within the source here we have the API now in this case the API is about Gateway or proxy or whatever you want to call it but it's the entry point where it actually doesn't do anything but it is the running asp.net for instance we have building blocks over here and this will go through the shed kernel you see it for building blocks shared whatever um once you kind of get the theory you can identify what it is right so shared you might have some identification maybe each system needs access to mongodb maybe each module needs access DF core using postgres maybe you need some logging maybe auditing things like that right so these are the building blocks this guy's built and definitely look at them look at them later now within the modules this is where you put your actual logic now a module you can write anything so I looked at the template here and we have clean architecture in here so let's say you have a big clean architecture code base you can first move to the area folders here as step one and organize it that way and then maybe you might choose okay that's not good enough for us and then you might say okay let's move these area folders into modules and just drag and drop them right now you will need to rip out that shade kernel piece so obviously talking about it's easier said than done but the the ideas there So within the module here this guy's chosen to go for more of a just straight up monolith approach kind of hence the name each module you'll find to write as a monolith because it is smaller and isolated but you can write it as clean architecture you can write it as vertical architecture it's up to you uh so yeah we can look at what he's done here there's features maybe some data access specific to that module maybe some entities uh strongly typed IDs based on that aggregate ID maybe exceptions and based on that you might have uh application and domain within IT services things like that just all splatted into a module there now I won't really go deep into it so that's just kind of the basics of what what he's done here uh and the the testing there you can test your shared projects you can test your modules nothing too you know unique in the test now so jumping back what should we use so we've got the idea of one uh a monolith anterior clean architecture vertical slices you can use the modular monolith with just a monolith in each module you can use a modular monolith with clean architecture in each module you can use it with vertical slices in each module you can mix it up you can do anything in in each module that's a lot of options like what should I pick well I think you need to look at the pros and cons right of each one do I want that really quick speed how long will it last how many people work on this is it just going to be built for a few months and then maintenance small touches but lasts a long time like take take some planning like you don't need to solve every problem that doesn't exist Engineers obviously like to solve a problem that's imaginary or doesn't exist yet so there's obviously like you know a trade-off again there's no exact answer in anything right but you know you can have knowledge and think about things to me uh you know have a play with vertical slices have a play with clean architecture see which one works within your team which one works for you then maybe if your project scales you can move to a modular monolith and the training within the team stays consistent if you pick the modules to be architected in that way that kind of fits your system so maybe the clean architectural vertical slices will write for your system at the time and then maybe it's scaled and maybe you're worried so maybe you do just move that same architecture but replicate it within the modules uh and then you're not going through crazy infrastructure where you're doing microservices but the option is there right if you have a Gateway maybe the Gateway points to one module and then you deploy another instance where the Gateway has one module so that is another cool piece of modular monolith where it can eventually become microservices with not too much code to be changed but again that's a whole nother talk so I'll just leave that as a hint to look at later now some resources here so I'll just show a few things to pique your interest for later if you're interested in clean architecture ssw has a rule site which is a collection of the best practices among a whole bunch of different things so we have a bunch on clean architecture so some that are an intro to the you know principles of clean architecture uh various things to apply it within a code base uh and random tips through sort of strongly typed IDs as an example they're pretty cool right small code change to just protect against civil things so you know a rule here on how to get it up and running within a code base random tips like that cool stuff uh so yeah that's the rules the template that I used for clean architectures up on GitHub here so you know check it out if you want make a change make a feature request whatever uh that's cssw template it has a big list of all the features it's got I didn't dive into it you know nearly as deep as you could let's talk here's the vertical slice architecture repo it's on my personal account here how you get set up and just simple feature list give it a star if you think it's cool uh and then this guy's uh modular monolith that we export a little bit give it a star it's definitely not easy to work in open source land and it keeps the guys motivated so I'd you know jump on and give him a start it's pretty cool all right so yeah if you've got feedback uh scan this thing it'll take you to a Microsoft form I appreciate uh any feedback you know good or bad definitely bad because then I can learn from it right and never make the same mistake twice so you know if you've got any feedback please please please fill it out um I will read it and make sure it gets action for whatever next talk so yeah in summary we just had a chat through the end of the pain and logical you know flow of these architectures over time of how we might have moved from a monolith to clean architectural things beyond that same with vertical slices you know how we got there and what it does and then obviously how to get up and running really quickly with both CA or VSA which is pretty cool and I really hope the modular model for something that piques your interest and you know you'll go and explore that later on because I think it's pretty cool uh and something to apply in larger code bases for sure so that's my talk thanks guys for listening along I really appreciate it thank you [Music] thank you cool so I've got Nick up here he's going to ask the questions we've got from the chats or the other officers so fire away Nick if there's anything well yep there's definitely been a few so thank you so much that has been a fantastic talk uh like Adam said it's a very important topic uh before we go to the online and the international questions uh are there any in the local audience yep up there so the microservice is like a way to host it it's the infrastructure piece where like I kind of I talked about with the messaging thing where if it's hosted within the same app you might have a vertical slice that's communicating using mediator something like that where it is within the same instance whereas if it's a microservice that communication between slices or modules or pieces is done over the network with like a service bus or a sidecar so it's the same concept but microservices is really painful to build in terms of the infrastructure like kubernetes and setting up you know Docker containers and scaling you know all that stuff is really complex if you don't need that scaling and infrastructure bit the vertical slices gives you the benefit of kind of isolating The Logical piece but saves the pain of the infrastructure of microservices so kind of the difference of course so that question there was just with regards to uh difference between uh microservices and BSA all right any other questions oh yeah so from the online uh we've had a statement made that ba a VSA is just uh clean architecture sliced the other way what is your response yeah it can be that way I think uh in the in a real app you'll probably see it that way I kind of looked at it on this slide uh it's really easy without the animations where it is just kind of rotated nine degrees so you could build it flipped on its head where it's just instead of clean architecture as projects you have it within that slice but you have the freedom to build it anyway so yeah it could be you could think of each feature folder as a clean architecture a little module good it's a bit of a reach but you could think of a vertical slice app if you're building it that way as a modular monolith now we're reaching here so don't quote me on this but you could think of each little slice as a module where you could be building that in a clean architecture way it's a reach but yes it's definitely possible in a way you could do it so it's something to think about another question that we received was uh what can we do to prevent code from one slice directly call encode another slice or maybe just rephrase it slightly how do we dissuade programmers from from that sort of cross-calling yeah yeah I think uh the the major thing is automating things away and I think you're a big fan of that as well we don't want to be having to check it at code review time or way too late so a really cool thing that I didn't touch on is architecture tests and that's a way to test kind of meta about what the code is so you can test that maybe folders aren't referencing other folders or even easier's projects or assemblies aren't referencing other assemblies so without architecture tests if you're building project-based modules or slices you get some protection against circular dependencies which you'd run into pretty quick if you're not doing anything with messaging but it does not stop you know one-way referencing so the step above that is an architecture test where it's just another unit test someone will run auto run in the pipeline whether it's like a pull request check or check on Main and say hey don't reference anything other than the contract or the messaging you know assembly where I we've got just think of a protobar file where you've just got all the contracts and it's like okay here's what I can send and here's what I can receive if you have a test like that you automated away and then you can again like I said I want to be able to sleep peacefully at night if I've got the test I'm more inclined to sleep peacefully I'm not worried that someone might butcher things up so that's the major way to do it another question we've got is does a BSA application require a shared kernel or is that just recommended uh so yeah the VSA app didn't have a shared kernel uh the the modular monolith did but there was some common code in the VSA application which you could think of as the shared kernel now I kind of touched on it with that you know painful example of putting every single thing you could possibly have related to one piece in the folder so if you didn't want to share any code within a VSA app you could follow you know something like that where you're putting everything whether it's SATA access scripts within each uh slice and then you'd have no shared code uh that the only exception being the infrastructure if you want it to be incredibly purest you would be even on the infrastructure piece we have a microservice per folder but I mean the expense of first of all developing that and running it you know the trade-off to me is way way out of whack but you know the options there all right so just one thing check considering that we have the ssw clean architecture Workshop does that mean in future we can look forward to the ssw DSA Workshop you might stay tuned for it we might be building one uh the option's definitely there but you know there's nothing locked in yet um but if there's interest there we might build one nice well those are the main questions that we've uh received unless there's anything more from the audience check cool no I think that's it that's a wrap thank you everyone cool thank you all right [Applause] foreign [Music] [Music] [Music] foreign [Applause]

Channel: SSW TV | Videos for developers, by developers

Views: 896

Keywords:

Id: tgi2eqKhhA4

Length: 97min 5sec (5825 seconds)

Published: Wed Sep 20 2023