Have you replaced your DB because of the Repository Pattern?

have you been able to replace your database implementation transparently because you use the repository pattern I know this seems like a controversial topic but I'm going to explain why I don't think it needs to be at all sure you're creating an abstraction but an abstraction around what I want to thank eventsor for sponsoring this video event store DB is a new category of operational database built for event sourcing cqrs and event driven microservices for more on events.db check out the link in the description now I think most of us can generally agree on this definition of what a repository is defined in the patterns of Enterprise application architecture or repository encapsulates the set of objects persisted in a data store and the operations performed over them providing a more object-oriented view of the persistence layer one of the reasons I think this becomes a Hot Topic unfortunately is because we're talking about different things we're talking about a repository sure and we can all get behind that definition except for it encapsulates a set of objects well what type of objects are we really talking about I found there are two ways that people are thinking about these objects used for repositories there's one side that's really thinking about them as a data model it's just a representation of how you're persisting data in whatever data store and the mapping that goes along with that the other side is really coming at it from a domain driven design perspective and thinking about a domain model entities value objects those units that compose an aggregate so there's really two sides and I think that's where some of the Hot Topic comes from is because people are thinking about a repository but they're thinking about it in a different way in what its use is some are thinking of it purely as data models and some are thinking of it more for Aggregates now regardless of which way you're thinking about it it may seem like you're using it the exact same way but there's a difference so we have a repository it could be fetching out this object model hierarchy this data model that has Basket in the basket has obviously many different basket items Associated to it and this can also look like an aggregate where we have different entities but there is a difference and that difference is behaviors with an aggregate were exposing different behaviors to make State changes our aggregate represents a consistency boundary we have these entities value objects within that represent a consistency boundary that's why we have an entity that represents the aggregate root and I'll show this in code to explain this more but we're exposing behaviors because we want to make State changes and that is a very key difference between what an aggregate is doing and what just an object model data model hierarchy is so to illustrate an aggregate in a simple way I'm using the eShop on web sample application so we have here is this basket service and this add item to basket method that's using a repository to get out our basket which is our aggregate route and it contains all the items the basket items so we then call add item on our basket now one of the simple things that we have here for consistency is that we don't want to add multiple basket items for the same product for the same catalog Item ID so we're just checking to see here if we already have one if we don't we're going to add a new basket item to our list for the quantity and for the catalog item that we've requested but if we do have an existing one already in our list we're just going to increment and add to our quantity how will we do this any other way we could have a transaction script because we have these entities we can have this logic with uh exists within the entities and we're going through the root the items don't know about each other but the root does the basket so that's where we have this logic living in the basket this is our consistency boundary of our aggregate our basket and the basket items so for not thinking about Aggregates we're not thinking about entities but rather we're just thinking about data models in an object model hierarchy this logic would still exist it would just exist higher up maybe in the example in our basket service but there's a definitely a separation between our data and what our basket represents and the behaviors that we're exposing when we're having entities in our Aggregates these are combined together and we're exposing everything through the root if we're talking about data models our classes just represent the data there is no Behavior with them that exists separately so the difference here is do we need to make some type of State change we want to have an aggregate as a consistency boundary we're exposing some types of behaviors to make those State changes or do we just need data why would we just need data well to perform a query so that means that we can get back to cqrs where we're thinking about well what are we actually trying to do are we trying to perform some command to make some type of State change or do we need a query just to actually get the data they're different uses so we think about it this way do we really need a repository to do both are we performing some type of State change where we want to get an aggregate out that route then maybe we want a repository for that purpose because again we're thinking about an aggregate as a way to have that consistency boundary because we're making some type of State change when we're performing some type of query do we need that aggregate no not really because we're not creating we're not doing any type of State change we just want to read data so that means that you may think about your repository in its implementation and how it's implemented differently on how you perform rights and get out in Aggregate and how you think about reads and where you really just want to get access to a data model so to illustrate a query I'm back in our sample application and this is going to be a listing of all the orders for a user we're using the order repository and we're getting all the orders out and the order items for each order in a list here's all our orders we're then taking this basically this aggregate out because that's how our order repository is working and we're then creating this view model that contains the order date we have the order items so we're creating a list of those the order number the shipping address the total Etc so every order in all of each orders line items if I look at actually where this is being used it's in our controller that's where it's generating it so it can get this view model for our view so let's take a look at the view as I mentioned we're just iterating over all the orders that we have but the key thing I want to point out here is that we're not actually using any of the order line items we're not we're not iterating over them at all we're just showing the order number the date the total the status Etc but because we're using that repository and that repository is thinking of it as this object model hierarchy it's always including the items because maybe we need to perform some type of operation on our aggregate but we're not we're just want data but we're really over fetching data because our use case for our query isn't the same use case as performing a right we're not making a state change we don't need all the data to encapsulate all that into our aggregate so that we have that consistency boundary it's a different concern so back to the original question thank you David Fowler for the inspiration on this video is have you been able to replace your database implementation transparently because of your use of the repository pattern now the answers to this question are going to be all over the place which is to be expected because everybody has different experiences you're gonna have some people that say no in 20 years I've never had to replace the underlying implementation of our database while other people are going to say yes we replace it every time in every project I've ever worked on and then other people mention about using the abstraction for tests however I think it's important to make the distinction on the use case what are we returning from a repository what type of objects are returning just the data model that's an object model hierarchy that really has no behavior that lives elsewhere or are we thinking about returning an aggregate in an aggregate route that is exposing Behavior because what a repository looks like is going to be different if we're thinking about just data models and for query purposes we're going to have a whole subset of methods that for different ways of returning that data lists of our data models our object model hierarchies in different ways for different ways of filtering it out how returning it an individual a collection Etc there's going to be different ways that we want to return that data because likely we're going to have different use cases for how we need to return what type of data that we need to return filtering Etc when we're thinking about Aggregates and making State changes that becomes a lot simpler because oftentimes we're just we know what aggregate we need to make some type of State change on so generally those repositories look like okay get by some identifier and save our aggregate that's what that repository looks like they're going to look very different and this matter is because what you're using as your data store changes what the implementation in and the repository might look like as an example I'll have a link at the very end of this video to another video I've done talking about the subtraction and using a repository as an example but the gist is in my example let's say we had a repository that was used for both reads and writes and we're using a relational database so our repository had all these different methods different ways of fetching out data and lists of data if you all of a sudden want to change our underlying implementation to be using event store and event sourcing that would look very different because we wouldn't be necessarily using it for all these different query methods to hit all our different event streams and to build up all these Aggregates we likely would have a separate read model for this so again how you're thinking about the model the implementation depending on whether you're doing a read write that changes what this repository is going to look like if you found this topic interesting and you want to chat with other software developers about topics like this you have questions you have answers or you have your own opinions you enjoy my channel and get access to a private Discord server check the link in the description on how to join if you found this video helpful please give it a thumbs up if you have any thoughts or questions make sure to leave a comment and please subscribe for more videos on software architecture and design thanks

Channel: CodeOpinion

Views: 25,363

Keywords: Repository Pattern, software design, cqrs, domain-driven design, repository pattern in asp.net core web api, repository pattern laravel, repository pattern c# mvc, repository pattern in asp.net core, repository pattern in mvc, repository pattern java, repository pattern flutter, repository pattern nestjs, repository pattern web api c#, repository pattern and unit of owrk with asp.net core 6, repository pattern with unit of owrk in asp.net core web api

Id: EwKhyp2kHME

Length: 10min 53sec (653 seconds)

Published: Thu May 18 2023