Gill CLEEREN: Clean architecture with ASP.NET Core | UCP2019

all right I think it's about time to get started you'll afternoon I didn't hear that good afternoon there's better all right so I hope you had a good lunch and now you're ready for some architectural stuff with asp.net core how many of you have been doing some asp.net core stuff already quite a few that's good I think dotnet core is really getting popular nowadays it's good so I'm not gonna be talking about any introduction any stuff around asp net core we're gonna talk more about how we can build something based on the clean architectural principles that is also a way that i built most of my asp.net core projects via the api is beaded MVC applications whatever they may be so well my name is Joe I'm here for the second time so thanks for having me again I'm Kim Belgium where I have my own company experience and I'm doing the CTO stuff there you can send me an email if you have any questions afterwards feel free to reach out I also post the slides on my personal website there as well I also do a lot of pleural sites been doing it for close to seven years now including a lot of stuff on net core and I'm also on blazer so my new course on blazer will be released in I think two weeks or so so it's gonna be a full course on getting started with blazer so that's gonna be an interesting one as well I hope um if you want to check out my courses that's the link that takes you to my speaker page on pleura site for all the courses like I said also including asp.net core 3 stuff um so what are we going to be doing today and actually I have quite a few legenda so where I may not be able to fit it all in so we'll see where we get um first little introduction of stuff setting the scene what are we going to be looking at so what is asp.net score bring it to the table where is it going to help us that's what we're going to start with like five ten minutes or so now clean architecture has will discover has to do with applying a number of architectural principles nothing new really now I'm not sure how many of you will know all these principles so I'm gonna give you a five to ten minute overview of these architectural principles that really are the foundation of an architectural an architecture based on the clean architectural principles and I will take a look at I built my applications so we'll take it from layers into clean architecture so you'll see the differences moving from the one approach to the next we may have to skip the other part where we see how are some other things are done in a spinner net core application as well but I do want to spend some time looking at how this thing is going to be testable because clean architecture is building with testability in mind so we'll take that into account when we do that sand and I do want to show you how we can do all the testing as well so I want you to work out out of this room after an hour with me the following the following knowledge that you have will have gains so I want you to understand what clean architecture is and how you can apply it in asp.net core applications and also see like I said if we have time to do some common tasks and including how you see that clean architecture can help you with testability and maintain maintainability in your applications all right so first like I said a small introduction and I'm looking at what we need us as developers to build modern applications modern web applications with asp.net core nowadays now if you look at requirements that people that people put forward from building modern web applications well there's quite a few but I think I digested the most most commonly used one in this line here modern web applications have to be highly available we have to make sure that applications are always up and running that of course goes hand-in-hand with clouds and scalability and scalability is of course the next one that is also a requirement for most applications that we build nowadays we also have to run on any device with a mobile device be that a desktop device be that whatever but they also have to be say host of all you can take the any device they also do server-side they have to be hosted on Linux because we move stuff into doctors nowadays we don't do plain windows hosting anymore we put our applications in docker containers and therefore they also have to be hosted on Linux and maybe even on Mac you also have to be highly secure that's quite a normal thing I would think that we don't build unsafe applications at least I hope we don't and also we have to offer a rich user experiences those are the the most typical requirements that that web applications have nowadays now if you look at Monday Danette is putting forward is bringing to the table well it actually let's say sauce all these things pretty much out of the box threat the scalability asp net score compared with plain asp.net MVC is built with scalability in mind it's so much more scalable because of the fact that the footprint is so much smaller it doesn't bring all the system web stuff that it used to do it brings only the things that it needs because it's based itself on dependency injection they will see that dependency injection by the way is also very important when we built our own architecture based on clean architecture it's also cross-platform so it's going to fulfill the cross-platform sorry any device requirement it runs on on Linux that of course also helps with the scalability because we can actually very easily move our application on to Linux hosting we can move it into micro services hosted in docker containers so all of that is pretty much built into the application platform and loose coupling will see that loose coupling is maybe the basis the basis of the all the basic foundation let's say of clean architecture and and that is also built in because asp.net core comes with dependency injection built-in you can change it it's it's very flexible you can change the dependency injection system but it's actually built into the platform so it makes it easy for you to also adapt and start using it it's also come it's also built as a with testability in mind it eats it's very easy to test you'll see by the end of the presentation that asp net for and if you apply clean prints clean architecture principles it's a very easy to test your application you get something like that server built-in maybe we'll have time to look at it so it's basically yeah built also with testability in mind it also has things like side by side you can do multiple versions of the applications framework side by side i'm not going to talk about that and like I said it's high performance and optimized for cross-platform hosting your application into docker containers on docker containers is a micro services architecture so all of these things are built into asp.net core we get them for free Microsoft has already taken care of that now if you look at what we are going to be looking at sorry is actually um we're gonna look at principles I'm not gonna be talking too much about really the code really because yeah the code is just code but look more at principles how to divide your application into several points so everything that's we're gonna be looking at here today is actually gonna be appliance it's gonna be applicable for just any type of asp.net core application you may be saying I don't do any MVC applications anymore right yeah then you can apply these principles fully for ASAP is that you build with asp.net course as well so everything that we see here today applies for MVC application RAZR pages plain MVC applications api's even for hybrid applications and maybe also even for blazer applications yes or no so it basically applies with all types of web applications that asp.net core is involved in somehow so all the principles will apply for all of these types of applications and a little side note you're talking about architecture this is a question I often get when I talk about asp net of course people companies come to me and say well should we build our next ASP or next web application that says a spawn as a single page application well it depends like everything is software we cannot give a clear answer it all depends on a lot of factors of course but I do see a lot of applications that are being built today as a spa but I think as part doesn't make sense there are a lot of applications that like blogs maybe web shops contant going to delivering websites web applications don't make sense really to build as a spa all the time if the team has little to no JavaScript experience it's very hard to get the team up to speed with with a fast-moving festival forward moving landscape that you have for JavaScript so it doesn't always makes sense right do you do a spa but let's not go too much in there um like I said everything that we see here today can be applied if you build a spa with angular which view whatever technology you want to use everything that you see here will be applicable for an API as well right so all these principles are fully applicable there as well so my advice in that area building a spa build a web application that has a rich front-end if you're building a web application or than a website it's it's something that there's a clear division between the two and it doesn't always make sense to build a spa it's not because your neighbor is doing it that you should also be doing it and of course this is the new kid on the block right who's been playing with Glaser few people only a few people right cool so I assume that you know what laser is it's gonna be the big thing coming out it's actually already out as a surface sized version but to clean the client side up version is coming out next May it's going to allow you as a developer to just use eShop in the browser of talking with an asp.net core back-end so it's gonna be C sharp all the way right and again everything that we see here today in this prints in this presentation can again be also fully applied when building blazer applications right is it definitely for 2020 D thing to invest time in because it's going to make you as a c-sharp developer capable of building rich web applications that weren't fully on the client even with offline capabilities and so on so if you don't like JavaScript 2020 is gonna be your here I think so um I'm not for the introduction um I'm gonna show you everything here today um based on on a working application because like I said I'm not gonna spend too much time looking at code to look hard at principles um the application that I use for this is my mouse there we go so the application that we'll be using is an application built by Microsoft because they also know how to do clean architecture that's good it's it's called the eShop on web they apply some principles I don't really like some things they don't I don't feel like our point amount but this is an application you can find a shop on the web you'll find it at Microsoft come slash that's that architecture and like I said they apply most principles very well here so we'll use that as our guide to look at how we can do this in asp.net core now I do want to show you the finished application I have to give you an idea what we're looking at here it's an it's a web shop right so you can click on on a product you can add it to the basket and there we go Visual Studio stopped working very good thank you very much to you yeah so it's a web shop right everywhere shop stops now and then so we'll see what it does now I did order a new machine so I think my machine is actually getting with jealous so there we go so let's try that again it was fantastic demo if it takes too long we'll already go on and interactive so well after the basket again trying it again there we go so how it seems to work very good then you see the basket you can increase the number of items and I don't think this is real work at science you're all small people here so you can then checkout you can log in with the user there we go because we're not like logged in and you already been placed right so like I said this is not really relevant to what we're going to be talking about here but you do not know what we are looking at in terms of functional design what we're looking at all right so there so now setting the scene has been done we've already lost 10 minutes so I need to hurry up a little bit um so now before we look at clean architecture um I do need to give you a little overview of some of the most common patterns or actually I should say the practicals that clean architecture is built upon right so clean architecture has to seen in in ten minutes or so is really nothing new let's it's really applying a couple of patterns in a good way but I do want to give you these patterns as well because you may not know them and then you may actually get a little bit confused right so these patterns are nothing new they are actually things that you probably already know and hopefully use but I do want to give you a small overview of these as well and these principles out there to get us into an architecture that is gonna be three things basically testable maintainable and loosely coupled right that's basically what we're aiming for with a good setup in terms of architecture for an application the one basically brings along with the other if an application is testable it typically means that it's maintainable and it's probably based on loosely coupled code because if you do tight coupling you have hard links between all the components and therefore your application is probably difficult to test because if you need to test a you're gonna have to bring in B and Bri brings in C and there and and so on as well so the goal is bringing up or setting up a maintainable testable architecture and in the end is easy to test and we'll see the unit testing at the end of the presentation so like I said a number of principles a number of architectural patterns make it possible sorry like I said these are not rocket science I hope that you know all of them if you know all of them very good then you can rest for 10 minutes or so if you do not know all of them please pay attention because like is like I said you're gonna have to apply them when building clean architecture in your into your applications they are separation of concerns dependency inversion explicit dependencies single responsibility the DRI principle the bounded context and persistence ignorance so like I said I hope they're not anything that you've never heard of but let me give you a small overview of all of these in a bit more detail and we'll start with probably the most important one no not more second important second most important one and that is separation of concerns I do hope that separation of concerns is something that you already know about because it's something that every should a software developer should know even if you haven't been around in software industry for too long so separation of concerns is basically saying you are going to split up your application into different blocks and each is actually going to do a specific thing right when you're add code you don't want to put every line or put all the functionality into one big bucket you actually want to split it out because of course otherwise it's gonna be hard to test things in isolation right you actually want to you don't want your UI to actually dive into your business calculations and then also go out to the database you don't want to put that in code behind that's how we did things in the 1990s and that's not how we do things anymore nowadays so we actually have to split things out a little bit more that allows us to test things in isolation and actually make sure that we only focus on what we want to test answer the business logic layer is a good example the data access layer they know about each other but they actually do their thing and their thing only that's pretty much the thing that you're going to do if you've been building applications in layers which I hope you have done so far well then this is pretty much it right separation of cruisers you can also do that on a different level on a class level and and it basically comes more into the single responsibility pattern the single responsibility is very close related to what separation of concerns is saying they're not exactly the same signals possibilities Morgan on an object orientation level rather than on on on an application level so to say but single responsibility is basically saying in object orientation sorry a class is doing one thing and one thing only right and if I need to change the class it should be because I need to change one thing and if I have to change it for two things well done basically no splitting two things into classes really that signal responsibility again something that you probably already apply hopefully because it's basically saying if you have a class it shouldn't be doing a and B and C because each across would you be a and eight only and if you're an if and if I need to bring in B then I need to bring in a new class and I need to bring in C classes don't cost a thing right you don't have to pay in Visual Studio every time that you create a new class that would be horrible so that's why you can create more classes with with their own functionality and that's what single responsibility is say now when you apply this on an architecture level rather than on a class level you basically are also saying I'm a data access layer is going to do data access only so it's going to do business rules my business layer it's not going to do data access that's pretty much the same thing but you can also pull that into a an even higher level and I think of microservices microservices are actually also applying to single responsibility play I Pat him say I'm more on a functional level then they should do one thing for example if you have a micro service architecture you could say well that micro service is doing customer management and the other micro service is doing product management and so on so they all have their own functionality their own single responsibility and that's basically what this pattern is say the third one is that's that's my number one really I think that's the most important one dependency injection / dependency inversion nowadays dependency injection is something that most people know hopefully but I do come across companies that where it's not really known I'm not really apply it and they think it's something very high up in the sky very complex to understand well it's definitely not what your order not want to do is have at compile time references between your components they should not be referencing be directly because then you create at copying and if B is doing the same it C well story it's not going to work because if you have at compile-time and run-time dependencies are fixed then your application becomes but by default order to test dependency inversion is going to say that the dependency Street point in the direction of the abstraction so basically what you're going to do you're gonna bring in interfaces abstractions and are going to be on top of the B and the C for example here so the a is not directly referencing b and b it's not directly a reference you see harder they will will creat the interfaces at compile time and through dependency injection at the runtime they are actually going to be fulfilled so you see there that is referencing the interface of b and b is interfacing the in F and see the interface C and at compile time they don't know about each other they don't know about the concrete pipe they only know about the interfaces about the abstractions yeah on the right and you see it compiles right at the wrong time it's still the same a knows by b and b knows about see but that's dependency injection is actually going to help us resolving these dependencies like I said ASP did call for the people have worked with it already it is built into the platform please use it don't start creating heart references put everything in a dependency injection container is going to make your life a lot easier and you see that that's being done in clean architecture all the time also be explicit about your dependencies this is small one really explicit dependencies means that your components should say what they need I need this and this and this dependency so this should be actually doing that typically in the constructor constructor injection is therefore a result of that more or less so explicit dependence is basically says if a component needs different dependencies it should say so rather than having for example properties that are needing to be fulfilled by dependency injection it's much harder because you don't know if your application is gonna work after good not to null checks answer when it actually needs to less readable code if like I said is a smaller one wheel um don't repeat yourself right don't you beat yourself sorry how did it again stupid joke so the DRI principle and again is something that if you apply layering today you probably are already doing you shouldn't be writing the same code twice because then you actually have to maintain it it's harder for maintainability you have to do it in two places and you probably will forget the second one if you do it in one place so make sure that your app your your code is in one place and one place only and layering like I said brings this if you have UI and a data access layer and a business logic layer the data access will do or do their taxes they will do all the data access and can be accessed from anywhere to do that right that's again a very simple thing and again this is persistence ignorance is a little bit related to that one it basically says don't go out and create your domain based only whatever framework you're using to do your persistence right if you think back of entity framework in a very very beginning and you didn't have the ability to the Perkis like you have nowadays you actually had to build it bring in that base entity I think it was called in the beginning in the very first versions of entity framework that's not good that's not clean code typically if you have to if you actually start making your code a little bit dependencies on a framework it's actually bad now you may be saying and because typically this is where people say yeah but maybe some point in my in the lifetime of the application we're gonna switch it from Seco servitor to Oracle who do that but anyway but anyway that is not typically the problem but if you make your dependencies so your entities dependent on a framework like I said database switching is not something that I've ever come across in an application slash time I do you have seen that for example we build the application today we build it with the clean domain clean pokers and tomorrow we start using Redis and then then of course if you have dependency in your domain objects on a framework it becomes harder because Reddy's I need to accept these entities as well so make sure that your domain your entities don't does not know about any persistent store it should be clean it should be handled down the line this is something that I've come across quite a lot I me built the application today we use sequel server and maybe tomorrow we put it in Redis and then of course things can work exactly the same the application is ignorant about the persistence store of course very good finally and bounded context this is something that's you may not have applied even if you've been building software for a long time rounded context is is basically something that is more commonly used in combination when you apply or with TDD and so domain driven design principles I'm not gonna be using because clean architecture by the way is also very commonly associated with DDD and I don't have the time to explain you all so DDD in 50 minutes then we have to do another hour or so at least but bounded context is a pattern that you see often being used in combination with DDD and it basically says from from a functional perspective you will divide your application into several functional blocks that's what you're going to be doing in that case so basically like I already said customer management is one part and and product management is not a part that's basically what you then are doing answer the the functionality each maybe with their own data store becomes like a mini application and a mini bounded context and I know I'm not saying it 100% correct but that's basically what the principle is all about this is also also used in combination with microservices architectures because then each microservice becomes their o because its own bounded context again with its own data store it's like vertical slicing through your application and the product management is one becomes one part the customers manage becomes another part and each of them becomes their its own micro service so with that out of the way we are pretty much on time actually very good I'm keeping my timing very good that's the first time so we don't out of the way you now have pretty much all the knowledge you need to understand what is in clean architecture so I think the next thing is because we of course came for clean architecture to see how we can actually move into building applications with clean architecture now clean architecture like I said is nothing complex it's nothing to be afraid of I am going to show it to you step by step I'm going to show you how you can actually go from an application that is today may be built with finally project and boom everything on one pile into clean architecture so typically when I visit companies I see let's say there are three possibilities and you typically see clean architecture used all that much you see a lot of applications being built all in once lace and then I will show you how clean architecture can actually be a little bit better so let's start with all-in-one now what is all-in-one only one is typically there we go it's typically the result of a manager saying to you as a developer I need a small application that just we're gonna use it just a couple of weeks and then we're gonna throw it away and after a couple of months it's still there and after a couple of years the entire business runs onto it right familiar yeah that is typically your monolithic application the developer says ok I'll do found the project and I'll store everything in one big pile and it's never gonna be thrown away but then you actually be getting an application that is fully self-contained typically one one project one DLL it's a monolithic application and technically there's nothing wrong with the one of it because you can still do everything correctly you can still do testing and maintain anything but it might not be the best solution in in in the long run because think of if you if you have to deploy that monolithic application into Azure how you're gonna do that now you have to basically take the application and you're gonna scale it we're gonna put a second server and a third server and so on and so on right that's what your end up with because typically things are gonna be mono they think you can't pull them into different parts so this is a screenshot of a small Melita capla keishon i'm not sure if it's readable in the back my apologies for that so basically found your project and then you start adding rosters and controllers and view models and I don't know what in that one big project and it starts growing and growing and it becomes hard to find just anything in there right because you have lots of control all sorts of views lots a few bottles and that sort of thing and maybe some at some point you say well I'm gonna move my classes or my domain into a separate the assembly it's gonna help you right you're still gonna have one big pile one big chunk of code it's all very tight together and that's not typically what you want um you do get a little bit of separation of concerns if you can really call it that you're gonna create hopefully different folders and it might be separation of concerns because then hopefully you put the controls in the controllers folder if you do controls actually I've seen I've seen places ready to enjoy that but anyway like I said it's not not an ideal situation to be in the long run because it actually although you do separation of concerns by putting things in the correct folders it's gonna be hard to find something no one is really applying let's say that the architecture is not applying that you actually use all these architectural patterns because you can put everything everywhere and nobody's really looking at it and every can a visual studio was still a compile the application and it will still run hopefully but that's not what you want to what you want to do so um let's let's forget about that let's not go into that area so you probably have been taught since you started developing ah you need to build your application your layers right who's been doing layers most people that's that's what you've been taught in school and and at the first jongup and the second job because we all do this right so we build a lasagna of layers that's pretty much what you do it's good that I don't do this for lunch because I know everyone would run out um so why do we do layers well we actually want to apply separation of concerns we want to diminish the complexity of the application and we actually start splitting up because the UI talk needs to go there and this is the business layer code and this is the data data access code so it actually is gonna be split up according to concerns that's good we're gonna apply separation of concerns again like I said there's nothing wrong with with layers don't get me wrong it's gonna be easier to find your stuff is gonna be you actually are gonna apply the dry principle because you're gonna build a layer that does just the data access and you're actually going to make sure that the code is going to be reusable and because all your business logic can actually use something of the lower end and your UI can use business rules which are in the date the business data and so on so technically it's okay right if you need to replace something you only have to replace it in one place that's also good so a lot of benefits come from applying lace and it is already a bit more loose in terms of coupling you can do dependency injection this one of course sir again like I said this is already a very big step in the good dimension now so this is what you typically do from a very high-level perspective no matter how you how many days because sometimes have a facade in there and so on and so on so um just from a high level you have your UI that talks with the business layer and that talks with a data access nation pretty much it right each layer has its own responsibility so singles possibility has also been applied so that's good now if you think of it in a bit more detail well the problem is that this thing is actually although I've split it up in layers I still have the problem that there are some issues in terms of for example deployment if I want to deploy this type of application I cannot say I'm gonna put the data access layer on that server and the business day from that server because technically what you have created although you have split it in layers you still have the hard link between the different layers because the data access the UI still references the the business layer the business day it still references the data access technically the business layer cannot exist even without the data access it's typically still a hard link so what you have what what is known as transitive dependencies you basically still have dependencies between the different layers and like I said it's already a bit more complex or what you have created so while there's nothing wrong with this approach and so this is what you then have you have the different project in Visual Studio the business logic becomes one layer the access that the data access lodging is layer and UI is also another layer in terms of deployment layering typically like I said doesn't really help you layering is not gonna allow you to all of a sudden say hey I'm gonna put this on that server did you buy on that survey on the business day from that server no and by the way clean architecture is not gonna guarantee that you're gonna be helped in that area so but I'll come back to that but so in in general although you have layers to your application the application is still gonna be typically deployed as one single unit there that's not gonna be solved by just doing layering into your application so from an outside there's still the same you have one consisting out of several projects consisting under several layers studies and you actually when you want to scale them you're still gonna have to copy the entire application on to different servers and put the load balancer in front of it and basically that's like I said that doesn't really help you in terms of firm in terms of scalability and deployment issues so there's still a full copy let's say running of the entire application on each and every server so in terms of if you want to move into container based solutions layers are typically not gonna help you because you cannot for example say hey my my UI needs more capacity than than another layer that's not possible right you typically will have to build your hand tired of put your entire application into a single container and then duplicate that over multiple container instances so typically it's not a very good approach because you might actually choke the application still on one particular piece right docker containers in general and micro service based architecture is then basically going to say well I for example my functional split so vertical where we have the the catalog for example is going to be a different micro service which can then have its own layering applied and then the the shopping basket for example is another micro service that I'm going when I have a lot of load on the on the back-end show you on the website we're actually going to scale up just the catalog control or the catalog micro service and then that that's basically what you want to be going again layering is not going to help us in terms of deployment alright so that brings us to while they like I said layers nothing wrong don't stop doing it if you do it today but I'm gonna show you how clean architectures is doing things so it's a little bit different so keep in mind you are business data access layer that's what you typically have in clean architecture we're gonna turn things around a little bit so um by the way clean architecture is nothing new and like I said it's not the Holy Grail it's not something new that I that I or someone else just invented it's typically applying a lot of good architectural principles and there's also a number of variations of in architecture that you find there's actually sometimes you see ports and adapters as the name you see hexagonal architecture onion architecture and that become clear why in just a second so this is pretty much always the same there's there's some minor differences between how they are applied but in general it's pretty much the same thing it's always the people pretty much the same thing and again also it's often used in combination with TDD but it doesn't have to be used in combination with EDD so you don't have to start doing DDD because you start applying clean architecture so in clean architecture what we're gonna do is we're going like I said turn around the dependencies between our different leaves typically we start with in clean architecture what is known as the application core and in application core you're gonna have your domain your entities and services interfaces and that's what it's going to be at the heart of the application the core is it's similar to you first and it has no dependencies whatsoever that means that you can do whatever you want in there without being disturbed let's say by external influences on the other hand in what we're not going to be doing anymore and so your core could actually be let's say compared with your business layer in this case typically in a layered architecture the business thing is dependent on the data access layer in this case we're going to turn things around like I said my application core is not gonna have any dependencies anymore the data access layer in turn now is going to be they all become dependent on that on application core so we're gonna turn around to dependency and so what this results in is the following what you see here is this is also why it's called onion architecture a little overview of how the application architecture is going to be set up at the core of the application or the code is actually your entities and interfaces lots of interfaces hence you also need to pendency injection to later on plug in the concrete in sensation you're gonna put in entities and interfaces at the very heart of the application that's the thing in the very middle and then still in the application core you're also going to write your whatever you call them main services are application services so basically all your business functionality you're gonna put in the application core that's the orange part together that's the application core and that as you see in Visual Studio in just a minute will have no dependencies on anything external we're turning things around we're actually going to bring in the dependencies into the application course we're going to make our dependencies point towards the application core so that means that the infrastructure which is typically project that those data access logging file access may be whatever you want to do is actually going to point towards the core that's what you see at the bottom you see a little arrow it's not really visible I hope the blue arrow actually points into the application core the UI same thing you I will actually be dependent on the application core right so we're going to turn dependencies around I may be thinking how am I gonna apply that well I'm gonna show you in just a minute and so basically I've mentioned this already ok so if that circular thing is confusing you a little bit this is actually the flattened sort collecting more or less to give you a more comparable view compared to the typical layered architecture so what you now see is that at the very bottom is your app core again that's the thing that was originally in the middle and your that has no dependencies so your business layers that we had before there's no more dependencies well actually have our UI be dependent on the application core and we'll also have our infrastructure project infrastructure layer be dependent on the application core how is this working well actually true interfaces and three dependency injection will actually plug the concrete instance iation of the interface is defined in the core into the core at runtime so the core can do its thing and it's all like I said built on the concept of dependency inversion this is a more extended graph I think it's something that I I stole from Microsoft at some point don't say it's recorded to them anyway so what we have here it's pretty much the same thing you have your application core web that's the website that's the UI and and the the core is at the bottom here that's the red one he was not readable and the green one is the infrastructure room is dependent on who well the blue one DUI and so you see that the that might not be read also the dotted arrows are compile-time dependencies and the the full errors are runtime dependencies so your application call will actually have a compile time dependency and runtime dependency on the application core it will need to know about it however your application core has no dependencies on anyone else your infrastructure so your original data access now has a dependency on the application core and through dependency inversion will actually resolve this dependency in just a minute why is this useful well because your core is gonna be like I said depend independent of any framework and the principles that we're seeing here are fully appliable applicable sorry that's forward applicable for asp.net core and we see api's even for other known has been in that core projects because it's just principles rather than something concrete but I'm gonna show it to you with asp.net core it's also fully independent of the used database because like I said your bulk of your code is actually going to be in that application core and it's going to be fully agnostic to whatever data store you're using thing back of persistence ignorance we want to have our application completely ignorant about the data store reusing and this is fully possible with this approach it's also fully independent of the UI again most of your code is going to live in the application core and it's not going to care about your wider is actually sitting in front of it and perhaps most important this is going to make your life easier because it's going to make your application much more easy to test now before we look at the demo quick summary of who goes where in your domain in your application core you put actually most of the code in most in a real life application at least you'll actually put your your entities so your domain you put in there you put services that work with that with those entities in there you put a lot of interfaces in there as well but you also put things like custom exceptions if you actually are applying specification pattern you can also put those in there because everything that is fully agnostic about the actual infrastructure is going to be placed in here right that's that's the goal very importantly your core should never have a dependency on infrastructure if you see doing that as I'm not doing it it's actually directly doing it wrong registered you will actually help you a little bit because you cannot create circular references because if your data access or your infrastructure is dependent on your application core the opposite is not possible right but in general you could actually add a third project and do like this type of references it's not impossible but it's technically possible so it's not something you want your core no dependencies if you see dependencies in there you're probably doing it wrong second layer to call it layer is the infrastructure that's when you put all the the things that are dependent on external stuff so data access file logging if you need to interact with Twilio to send SMS whatever all that stuff goes in that infrastructure project and the third one is that the UI basically whatever you want to use MVC razor pages api's whatever that's basically your you while a that's gonna rely on the stuff that is in application core technically you should have a dependency between your UI and your application core and you may not need an application sorry a dependency between your UI and your infrastructure if it's just in asp net course today you will need it if you use the built in dependency injection system I will show that in the in the demo so um let's actually go to visual studio now and let's take a look at how this is applied here in code so if we go to visual studio you actually see under the source here let me make it a bit bigger that there are three projects an application core and infrastructure and the UI so the web application right so now what you'll now see is that let's let's start exploring let's take a look at dependencies like I said you should not have any dependencies in here if you see dependencies on Azure frameworks if you see a dependencies on EF core whatsoever shouldn't be in here then someone actually cross the border and actually did something that it should be doing you can slap them say that I've said it so there's nothing in here so it does nothing that has to do with dependence is that just a small framework to do some guarding but that's that's okay right so everything that has to do with with with external external influences shouldn't go into the application core so by this in here well your entities over here plane entities for example the catalog item here that's a plane class it has a base entity the base entity is just an empty class with the ID property in there so it's not a real framework dependent thing and also what you see in here are aggregates aggregates are also being used sometimes aggregates if you have dependent entities it shouldn't be used standalone let's say and you're gonna build them as aggregates you can also put them in here because that's still part of the domain with secondly interfaces lots of interfaces typically in a real life application you'll have tons of interfaces because everything that you that your application needs to do needs to be described by an interface and only at runtime well these these interfaces be resolved what you see is that you have a couple of types of interfaces over here you see for example the I think there's actually one in here so you see here that under services we have basket service I also have an interface I bounced code service right because the boss get service in in itself is the main service it's actually a service that does business rules and maybe calculate something in the Basque and and that sort of thing so that's actually stuff that can live directly in the application core but you also see under the interfaces that we have the ia sync repository and that is actually not going to be implemented in the core it's going to be implemented later on in the infrastructure but you do need the interface here for example if you go and look into the basket service you'll see that it has in fact a dependency on is Inc repository we don't resolve it we only resolve it at runtime tree dependency injection so this has a dependency on the ia sync repository implementation if that gonna be EF corn fine is it going to be something else as well that should be okay as well if you look at the is Inc repository for example this does some basic stuff like adding star entities getting entities to the typical repository stuff so that's is it that is in here so a lot of interfaces sometimes things like exceptions that those can also go in here because they need to be thrown by your business your application core rather than your infrastructure if you don't look at the infrastructure part you'll see typically in a real life application many dependencies things like EF core identity that sort of thing all going to be in here right so all that stuff is gonna be directly referenced from your infrastructure lave and your infrastructure also if you go and look empty in projects it's gonna have very importantly a dependency on application core why is that well of course for example it needs and implement the in situ doing it but it needs to do an implementation of the ia sink repository that's why it needs to know about your application core right so we actually write the implementation of the is Inc repulse it directly into this infrastructure layer and at runtime we'll the infrastructure layer be plugged into the application core and will it be resolved through dependency injection that's what we're going to do so we can develop the entire application code without being bored let's say by Eddy infrastructure stuff all it's going to be kept inside of this project in an in a nice and clean way there's other stuff in here like add order repository and that sort of thing and also implementations of services there's just one here but think of a login are looking is it negative well this could be an implementation of an SMS sending email something users truly or something all that stuff can actually live directly inside of this infrastructure so as soon as it goes outside of your applications domain what I'll actually typically will go inside of the infrastructure project and then last one the website the UI of the application and the application itself as a web application itself technically should only have a dependency on the application core and I mean technically not really technically because technically it needs two dependencies so if you look at it from a claim architectural point of view you should not directly reference most of them the infrastructure project why do we need it here because of the way that dependency injection in asp.net core is set up asp.net core uses dependency injection in its startup it actually goes through the list of all services as you can see here for example the I order repository and all the repository the I a single positive is a negative also all the implementations that are built into the infrastructure are reference directly from the started that's why you actually need a reference to the applications sorry to the infrastructure project from the web project so typically you wouldn't need it because in fact your applications UI should only know about the application core and the infrastructure stuff is gonna be plugged in at runtime now before I continue and I still have them so I'm gonna hopefully you don't mind I'm gonna go like five minutes over time so I hope you don't want um you know how are we using the application core from from the from the website I haven't shown you that but things like the controllers like I said be that API speedin MVC applications they will need to access your application score at some point and they will need to access the business logic that's quite normal but I do see even if even as if a set up applications built on on clean architecture I still see developers writing tons and tons of codes in applications controls right I'm not a fan of that i I don't like it's because applications controllers they're like traffic agents they should say what should be done but they shouldn't be doing it themselves their managers they don't know what they don't they know what to do but they don't know how to do it that's what it asked you to do it right that's what I manage is all about so controllers is the same thing they shouldn't be doing too many things they should say well now we need to do this but they don't they shouldn't be doing it themselves if you make controllers too smart yes I can commit to make it order to test so you see a lot of people doing actually everything directly into controller like I said not something that I prefer a better solution is using some type of service in the UI a view only service that's saying when you actually have the logic built into a separate class that lives inside of the web project that then can in turn use the application core so you make your controls unless code by default maybe the best and cleanest way is actually using a more command based approach where you actually use something that is built on the principles of sequence you actually creates or you create an object that basically contains all the information about what needs to be done and you then throw up that object basically and someone is gonna handle that and then you make your controller completely agnostic of what needs to happen and that can easily be done through a framework for example maybe mediator if you ever heard of written by Jimmy Bogert very nice framework that does exactly that you ran an object that says well this needs to be done we need to create an order so we throw up all the information about the order it's gonna be handled automatically by something by handlers basically and that's all handled by mediator so let me show you that and we can do that so I'm gonna show you first if you look at the controllers you see here that there's a couple of controls in here I think the order controller is it's an API controller doesn't matter this is a good example of a controller that already just does too many things right it goes out to the repository which by the way in my opinion should not happen this is this is one place where I actually don't agree with the way that it's done here I would actually do this directly on the application core and at the application core do this right so that that also avoids direct references into the over the repository in this case so but anyway what you see here is that's in my opinion is too much code in here right so you actually do all that stuff inside of the applications controls that's probably not the best place to be in a managed solution is I think it is the catalog controller the catalog controller as you can see it's also an API controller but it's already doing a lot less inside of the controller it uses a few service a class that contains the code that originally was inside of the controller but is now only being fully managed inside of the applications web applications can look few model service it's just a class that actually does all the interaction in again with with in this case the repositories and we humans right so it's cleaner already your controls become less burdened by all the stuff that needs to happen a third a final approach is what I just said is when you actually go through for example mediator so in this version of the application and it's not loading the application there we go something went wrong here so in this version of the application there we go so are we what are we going to do so this is based on mediator and it's actually going to create objects that contain what needs to be done for example this application is using a feature based approach as you can hopefully you cannot see that so you see here inside of the solution Explorer that the application is not built into features and so we haven't a future for example to work with the orders to get my orders that's a particular functionality within the application and there is an object a class that that defines what needs to be done and for example I need to get in a request for getting my orders so all the information to get that information is created inside of this get my orders object and it is actually used from from the order controller that's a very good place to use this one as we see here that we have again that same API controller but now instead of having a view service we don't have any tight coupling anymore granted we have an object that contains all the information about what needs to be done that's to get my orders object it just contains the user name that's okay but it will actually sent or it will actually use the media that has this as a messenger so we throw up that object so it crowded in here mediator will pick that up and it will automatically be handled by this get orders handler that you see over here right now you see here that there's an object I get get my orders handler that is going to be in a loosely coupled way handle that the handle method is going to be called automatically it's gonna handle automatically they get my orders request and it's going to send back in this case and I in available of order few models and that's in my opinion a very clean way not to create any tight coupling between the different components so um the last thing I want to show you because this is what you set off with so [Music] this isn't this is hidden slides right don't do it's not laughing I can actually continue for another hour I think but anyway so the the final goal but this is this not testable right can we actually easily apply different types of tests can we write or can we test what you set up in unit tests in an integration test well let's see let's see how is banana core handles that so let's go back here into visual studio and let's take a look at the test for you like I said you can download this code from the Microsoft website and I'm not gonna show you all the different types of tests which are in here let's for example take a look at the unit tests so the unit tests and let me quickly jump back to my other branch when one second so you see here that there's actually application tests now unit tests ready for the application core so there's unit tests for the entities and for these services let's take a look for example at the services the reason that this tests for the entities is that because sometimes the entities also have a little bit of functionality in them to it for example check something or the entity I'm going to show you that but that's for example take a look at the basket service tests so what we want to test is functionality in the application core right so in this case we're going to test the the the deletion of a basket something that lives directly in the application score a basket service implementation so gonna test it but as you can see at the top that thing has a dependencies that that that service has a dependency on the eye a sync repository so what we're going to do here is very easily bringing this is using the monkey framework it's going to create an implementation a mock implementation of the eye a sync repository in basket it's angery to create a new basket itself over here because we're testing in this case the boss could serve is not the basket to bring in two items into the basket and we're going to use again the monkey framework to make sure that that method is is known to the maquis framework and are we going to invoke the basket service so as you see by splitting it up it's actually very easy to test these services in isolation it's actually possible to bring in mock verges of the repositories to make sure that you can easily test your you know your applications core services in in this unit testing iPod and so with that I'm already over time so I am going to let you go further so um I hope I've given you an overview of both asp net core very briefly we didn't look into detail by the asp net core but i'm i hope I've given you some some food for thought to think about how you set up the applications architecture clean architecture has helped me quite a lot and I think it will help you as well into building applications that are much more maintainable and testable in the long run it takes a lot to get used to because there's a couple of things that have turned around compared to what you've been maybe doing for years but I guarantee that in the end is going to make your application and your applications developer life a lot easier in the long run I hope you enjoyed it thanks for being here and I hope you enjoy the rest of the conference [Applause]

Channel: Update Conference Prague

Views: 7,446

Keywords: Update Conference Prague, Update Conference Prague 2019, Update Conference, .NET Core, Gill Cleeren

Id: BxtHt7tsX-c

Length: 56min 39sec (3399 seconds)

Published: Mon Apr 06 2020