I have found some old questions, but I doesn't really answer or clear my doubts.
Repository Pattern + Unit Of Work: it is from 2012, and they tell that really to the repository pattern is not needed nowdays. Really I would like to know if repository pattern implies always unit of work and another aspects. Anyway, it would be to know another opiniones more recents if really repository pattern is useful or not today.
DDD - the rule that Entities can't access Repositories directly: this is a good post, but it desn't talk about unit of work.
Also I have asked another questions that are not answered in this posts. So I open a new one.
I am reading some examples how to implement repository pattern, thinking in a DDD architecture.
The pattern is called repository pattern, but many of the examples that I have seen implement the both and it seems that it is a unit, it has no sense or it is not good to implement only repository pattern, that it is needed the unit of work too.
Here are some examples, that they have small difference but it is the same one to do:
https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
https://www.youtube.com/watch?v=rtXpYpZdOzM
In this examples, they use the repositories through the unit of work, so they don't use directly the repository to say in some way (really the repositories are uses because they are properties in the unit of work).
So my questions are various:
1.- When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?
2.- If it is implemented the unit of work, is it recommended to access the repositories only throuth it? Because in this examples, it is posible, in the consumer, instantiate the repositories and the unit of work. Wouldn't it be better to avoid the consumer to can use repositories and only create the unit of work?
3.- In the second link that I put, in the video, it is said that the repositories shouldn't have methods like update, that this is not the responsability of the repository, but in most cases of another examples, I always see the update method. So is it really a bad practice to have an update method in the repository? In this case, if I don't have this method and call the complete() method of the unit of work, it will work because behind the interface, the implementation uses an OR/M, but if another implementation doesn't use it, I have to notify in some way that the entity was changed. I guess an update method is the most easy to do it.
Well, in summary, I would like to know if really means to have the unit of work too or not.
Thanks.
When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?
From Evans, 2004
Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything.... the client presumably has the context to correctly initiate units of work.
So Evans considers them to be separable ideas.
Implicit in Evans's writing is the idea that the information of the domain model is stored in a single relational database; which means that transactions spanning multiple aggregates are fine, because the database ensures that information is persisted atomically. But when you start looking at alternatives to a monolithic SQL database, robust persistence is... tricky.
A lot of modern writing eases some of this by adding a constraint that aggregate boundaries and transaction boundaries are aligned. In this kind of a design, you might reasonably factor the transaction management into the repository facade.
As a reader, we have to be really careful that we understand the implicit constraints of the author's context.
it is said that the repositories shouldn't have methods like update, that this is not the responsibility of the repository, but in most cases of another examples, I always see the update method
Evans again:
The ideal is to hide all of the inner workings from the client (although not the developer of the client) so that the client code will be the same whether the data is stored in an object database, stored in a relational database, or simply held in memory.
There are a couple problems with this ideal
Collections simply held in memory don't have distributed failure modes like the other candidate implementations
When is the change I made visible to others is an important design consideration
So you end up with people choosing different repository interfaces depending on how/if they decide to address these issues.
The important idea to recognize here is that REPOSITORY is a pattern; something we expect to have different expressions depending on the system of forces at play.
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander, A Pattern Language (emphasis added)
Related
I want to ask if it make sense to use the unit of work with repositories on a project following the domain driven design philosophy and clean architecture or it doesn't make more sense and the generic repository pattern is sufficient?
Martin Fowler describes a Unit of Work as
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
The Unit of Work pattern is listed under "Chapter 11: Object-Relational Behavioral Patterns" in his book. Thus it applies to the implementation of a repository.
In DDD you define aggregates and you usually pass the aggregate root to a repository to save it. Now it's up to the repository implementation if it uses a unit of work, because it must coordinate the execution of multiple statements send to the db, or not. Maybe you are using a document oriented NoSQL db and just post the serialized aggregate. In this case you don't have to coordinate actions, because there is only one update action - a
put request.
I think that the Unit of Work pattern still makes sense in a clean architecture, but only in the repository implementation.
Lets assume we have separate read models so that we use repositories only on write side, not on read side. (and this question is all about write side)
Also, lets assume one of our goals is to have full Aggregate/Entity encapsulation in a way that they expose only behaviour and not state. (meaning, no getters/setters)
Next, lets assume we dont want to use ORMs nor reflection for getting aggregate internals from within repository.
Obviously, one of the solutions left is that aggregate itself exposes its full state as a VO/poco and hand it over to repository. Repository would then know how to map it to DAO and save it.
Now, on many places i read that repositories should accept aggregates themselves.
Question is: why? What is wrong with aggregate expose VO of its state, hand it to repository and let repo do the save based on it?
Benefit is full & clear aggregate encapsulation.
What is wrong with aggregate expose VO of its state, hand it to repository and let repo do the save based on it?
That approach violates some of the other assumptions of the domain modeling idea.
One of those assumptions is that the key business logic and the "plumbing" should be separate. The fact that you need to get a serializable representation of the aggregate is an accident of the fact that you are trying to write state into a stable storage (that step would be completely unnecessary if you were keeping the aggregate cached in memory).
A second assumption is that using "objects" to model the domain is a good idea. If you were using a functional approach, then of course you would be saving values, rather than objects.
It helps, I think, to keep in mind that the context of the solutions we write has changed a lot in the last 15-20 years. Patterns that make sense for a localized application with long sessions that include many interactions don't necessarily make sense for distributed stateless applications, and vice versa.
that pattern cause you to sacrifice aggregate encapsulation
No, it doesn't - asking an object for a copy of some information in a previously agreed upon representation doesn't violate encapsulation. See Kevlin Henney, for example.
What it does do, however, is require interfaces suitable for two different collaborators: your applications, that care about the business rules, and your repository, that cares about persistence of representations.
I am trying to learn about details of domain driven design and i came to this question.
I found many examples with:
Defining repository interface within the domain
Defining repository implementation somewhere else
Inject repository interface into aggregate root
On the other hand, there are examples that strictly go against it and do all repository related stuff from service.
I cannot find authoritive answer and explanation: is it considered a bad practice and if so - why?
I cannot find authoritive answer and explanation: is it considered a bad practice and if so - why?
Yes, mostly because a number of different concerns get confused.
Aggregates define a consistency boundary; any change of state should be restricted to a collection of related entities that are all part of the same aggregate. So once you have looked up the first one (the "root" entity), you should be able to achieve the change without needing to examine any data other than this graph of domain entities and the arguments that you have been passed.
Put another way, Repository is a plumbing concern, not a domain concern. Your domain entities are responsible for expressing your domain, without infrastructure concerns getting mixed in.
To have, for example, Aggregate.Save() method that would inside use IRepository interface to save.
Aggregate.Save() definitely indicates a problem. Well, two problems, to be precise: Save probably isn't part of your ubiquitous language, and for that matter its likely that Aggregate isn't either.
Save isn't a domain concern, it's a persistence concern - it just copies data from your in memory representation (volatile storage) to a durable representation (stable storage). Your domain model shouldn't need to know anything about that.
One of the reasons you found "many examples with" is that getting these concerns separated correctly is hard; meaning you really need to think deeply about the problem to tease them apart. Most examples don't, because teasing things apart isn't critical when you always deploy everything together.
Using DDD w/ Clean Architecture, I'm instantiating all of my dependencies (e.g. Repositories and Services) first and injecting them into my UseCases. What I've noticed over time is that my list of dependencies for each UseCase has grown quite large over time. For example, my UseCase uses 3 Aggregate Roots so I have 3 repositories. Not so bad. But, as I add more features, I find myself adding Domain Services or more Repositories and having to inject them into the UseCase Constructor as well. Is it ok to have 10+ parameters in a UseCase Interactor? I've always thought having more than 2-3 parameters is a code smell. Is there a better way to handle this? Thank you in advance.
Having to many dependencies in constructor is definitely code smell. It's not very easy to handle it and often time it's more matter of experience and skills, but basically you need to look at your system from different perspective and check whether some services/aggregates can be substituted (merged) by new one, which is dependent on your old ones. Than this new one can eventually prove useful also in other places in your system, so you will reduce your code duplicity. You must just follow SRP.
You can find nice example here:
http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/
After reading Evan's and Nilsson's books I am still not sure how to manage Data access in a domain driven project. Should the CRUD methods be part of the repositories, i.e. OrderRepository.GetOrdersByCustomer(customer) or should they be part of the entities: Customer.GetOrders(). The latter approach seems more OO, but it will distribute Data Access for a single entity type among multiple objects, i.e. Customer.GetOrders(), Invoice.GetOrders(), ShipmentBatch.GetOrders() ,etc. What about Inserting and updating?
CRUD-ish methods should be part of the Repository...ish. But I think you should ask why you have a bunch of CRUD methods. What do they really do? What are they really for? If you actually call out the data access patterns your application uses I think it makes the repository a lot more useful and keeps you from having to do shotgun surgery when certain types of changes happen to your domain.
CustomerRepo.GetThoseWhoHaventPaidTheirBill()
// or
GetCustomer(new HaventPaidBillSpecification())
// is better than
foreach (var customer in GetCustomer()) {
/* logic leaking all over the floor */
}
"Save" type methods should also be part of the repository.
If you have aggregate roots, this keeps you from having a Repository explosion, or having logic spread out all over: You don't have 4 x # of entities data access patterns, just the ones you actually use on the aggregate roots.
That's my $.02.
DDD usually prefers the repository pattern over the active record pattern you hint at with Customer.Save.
One downside in the Active Record model is that it pretty much presumes a single persistence model, barring some particularly intrusive code (in most languages).
The repository interface is defined in the domain layer, but doesn't know whether your data is stored in a database or not. With the repository pattern, I can create an InMemoryRepository so that I can test domain logic in isolation, and use dependency injection in the application to have the service layer instantiate a SqlRepository, for example.
To many people, having a special repository just for testing sounds goofy, but if you use the repository model, you may find that you don't really need a database for your particular application; sometimes a simple FileRepository will do the trick. Wedding to yourself to a database before you know you need it is potentially limiting. Even if a database is necessary, it's a lot faster to run tests against an InMemoryRepository.
If you don't have much in the way of domain logic, you probably don't need DDD. ActiveRecord is quite suitable for a lot of problems, especially if you have mostly data and just a little bit of logic.
Let's step back for a second. Evans recommends that repositories return aggregate roots and not just entities. So assuming that your Customer is an aggregate root that includes Orders, then when you fetched the customer from its repository, the orders came along with it. You would access the orders by navigating the relationship from Customer to Orders.
customer.Orders;
So to answer your question, CRUD operations are present on aggregate root repositories.
CustomerRepository.Add(customer);
CustomerRepository.Get(customerID);
CustomerRepository.Save(customer);
CustomerRepository.Delete(customer);
I've done it both ways you are talking about, My preferred approach now is the persistent ignorant (or PONO -- Plain Ole' .Net Object) method where your domain classes are only worried about being domain classes. They do not know anything about how they are persisted or even if they are persisted. Of course you have to be pragmatic about this at times and allow for things such as an Id (but even then I just use a layer super type which has the Id so I can have a single point where things like default value live)
The main reason for this is that I strive to follow the principle of Single Responsibility. By following this principle I've found my code much more testable and maintainable. It's also much easier to make changes when they are needed since I only have one thing to think about.
One thing to be watchful of is the method bloat that repositories can suffer from. GetOrderbyCustomer.. GetAllOrders.. GetOrders30DaysOld.. etc etc. One good solution to this problem is to look at the Query Object pattern. And then your repositories can just take in a query object to execute.
I'd also strongly recommend looking into something like NHibernate. It includes a lot of the concepts that make Repositories so useful (Identity Map, Cache, Query objects..)
Even in a DDD, I would keep Data Access classes and routines separate from Entities.
Reasons are,
Testability improves
Separation of concerns and Modular design
More maintainable in the long run, as you add entities, routines
I am no expert, just my opinion.
The annoying thing with Nilsson's Applying DDD&P is that he always starts with "I wouldn't do that in a real-world-application but..." and then his example follows. Back to the topic: I think OrderRepository.GetOrdersByCustomer(customer) is the way to go, but there is also a discussion on the ALT.Net Mailing list (http://tech.groups.yahoo.com/group/altdotnet/) about DDD.