.NET | DDD Specification Design Pattern In under 10 minutes

alrighty so in today's video we're gonna overview the application registry service and we're gonna take a look at the specification pattern that has been implemented over there my name is vasilia lanik and you're watching the.net architecture Series where we are building a notification system from scratch using Industries best practices in the previous video we have touched the application ready service itself in the context of enabling and adding pagination and sorting to our queries today we're going to take a deeper look into how it was all implemented and add the specification pattern that we have in other method of our application registry let's get started with the contracts we have briefly touched it previously so we have the I application repository which has two methods the get list async where we have enabled our pagination and the get by code where we have implemented our specification pattern the query itself is only one the get application list query which goes over here and the models themselves are pretty straightforward we have application which has code name and list of events and the events themselves have basically only a code and a name now if we go over to the implementation of the application registry over here we have more folders which are basically cross-cutting data infrastructure routing and services let's start off with the routing and over here we have the application endpoints so the next thing is the application registry installer where we basically have a couple of methods first of all is adding the application registry service where we specify how we want to configure our application DB context next we add the scoped application repository implementation to the I application repository and over here we have a decorate and I'll live over here somewhere or in the notation I'll link to a video where I go in depth how we can Implement decorator pattern inside our system so this is basically a cache decorator for our I application repository over here we have the application model migrations where we basically get an application DB context then we run our migrations and they use average endpoints where we want to use our endpoints to get to our application service next we have data which is really big but it's pretty straightforward so let's get over with the models we have the application data model with a code name and the list of event data models over here we have the event data model basically code name and reference to the application itself some people might want to use the models from over here inside their Entity framework I don't really like that since I want to let the contract part evolve on its own and let the event or the data models have evolve on their own so I don't like coupling myself to the models from the contracts in this regard next we have configuration which is a basic int type configuration I also have a video on this I'll link it over here somewhere where I go over how to correctly implement the configurations the event data model configuration is really similar we have a defined composite key defined over here a code and an application code we have a proper the property marked as required and the relationship over here next is the mappings and this is essentially it's just some projections that some custom projections that we have over here in the later video we're gonna go over mobster which is overkill for two properties and a single list of other objects but we want to go over it nonetheless and see how it can be configured for larger projects and larger objects the next folder is migrations basically an initial migrations for these two models and we have the seed which we can use to run our initial settings so we have some data over here and we're basically adding it inside a migration in order to enable the seed applications we should go to the application DB context over here and take a look at how it is configured so we have injected token service for future reference when we will be implementing uh multi-tenancy inside our application but for now we just basically apply configurations from this set assembly and over here we specified that we want to see the applications so that's basically all you have an extension method static extension method over here where you define the data that you want to see it and inside the application DB context you basically call that send method we should without that the introduction is finished and we can go to the specification pattern itself so let me close all these tabs the specification is a really neat software design pattern that is frequently used in domain driven design context however it can be applied in other particular contexts as well essentially we will be just recombining different business logic rules in order to get a Boolean result in the end today's explanation is you basically check if your object or your data myths specific criteria to get started with the specification we should go to our shared Library over here and to the specifications folder right here we have the specification class which is a public abstract class of T where T is a class and we have a protected Constructor which receives some form of criteria besides the criteria itself we have a couple more properties where we have the include the order by order by descending which basically are just some functions and the include is basically a list of objects that we want to run our queries in any frame so we can run application and then just include the application events that cells we have ordered by descending two methods to add include and add order by and order by designing if we need to do that and this is basically everything from the specification part so all our other specifications will inherit from the specification class and basically set up in their their own criteria for matching the application beside besides this abstract class we need a query Builder that is going to run our specifications and it's over here the class itself is pretty straightforward so we get an iquerable of source and we get a specification next we're basically just assigning the source to a query if the specification criteria is not null we just basically run a where Clause with this certain criteria over here next we basically run an include query aggregate everything we need from the include list we run some order by if it's not no else if we run an order by if it's not null and else we basically order by descending and we return the resulting iquerable now let's take a look at some specifics and we're gonna go to the specifications folder over here and we have application with vents by code specification which will basically retrieve the application with all its events by a specific application code it's pretty simple over here the class itself looks like this it inherits from the specification and mentions that it's working with an application data model and inside here we have the basic criteria where we specify that we want our app code to lower to match the application code that we receive inside the Constructor so we can have a custom Constructor where we pass some specific string and then we will call the protected Constructor from the specification itself with the criteria that we want to pass in so our criteria is the code to match the one that we have provided over here besides that we want to include our events inside our IQ variable since we want to query the events as well and we want to add order by code we can as well just add order by descending and add other includes in here as well so it will resolve everything inside the query Builder itself if we want we can chain multiple specifications in a row which I did in some other projects and the result was pretty neat since we've reduced the amount of code and the amount of two lower and checks like that throughout our repository code base now let's see how this looks inside our service so we go to application repository and we go up on top to the getby code async method and over here we have the specification query Builder where we specify that we want to build a query on top of our context.applications and we have this one specification which is the new application will developed by code specification and we pass in the code that we had received inside the method itself then we run a first sort default async with the cancellation token passed and we return this application itself it's pretty easy and you can see how this reduced the amount of code that we have over here and basically in the future whenever we will need to get an application by code we will no longer need to remember that we need to get the code to a lower case and then compare it to a lowercase code that we received inside the method everything is taken care of inside a single place over here which is really amazing if you ask me so that was it for this video we went over the application registry implementation and especially the specification pattern itself which is pretty easy but still offers you a lot of power behind the scenes in the next video we're going to take a look at the cross-cutting concerns for the application registry and small spoiler we're gonna have a deep dive into Cash topic inside an asp.net application and everything you need to know about cache patterns how to use cash and all of that I'll leave over here somewhere a couple of videos that you can watch preventively about how you can Implement cash with ready since i.net core and yeah see you next time

Channel: Vasilii Oleinic

Views: 3,085

Keywords: dotnetcore, dotnet, .net, API, REST, DDD, Modular-Monolith, Architecture, Clean Architecture, Clean Code, Repositories, Design Patterns, Patterns, Solution Design, Design

Id: v6Mo3w6ohHk

Length: 11min 5sec (665 seconds)

Published: Sat Sep 09 2023