I have a scenario where I have an aggregate root called "Project". Each project is in a specific order based on a DisplayOrder property which is basically an integer. There is no entity above a project that would be better suited as the aggregate root. What is the proper way to model the behavior to change the order of a project in relation to all other projects?
The logic to accomplish this is simple. Change the order of the project being moved by calling its SetOrder() method, and update the order of all the other projects around that need to be pushed down to make it fit by using the same method on each. Then they would all need to be saved as a group to guarantee consistency.
Here is the line of thinking we have had so far, and the two solutions we are trying to decide on:
1. Create an aggregate to represent all the projects as a "List".
This would create the concept of a "ProjectList" aggregate root which simply has a "MoveProject" method to take a project from one position in the list and move it, but can be saved as a whole using a repository. I believe this is a bad approach because it seems like we are manufacturing an aggregate that isn't really an entity and has no identity just to model a behavior.
2. Use a domain service.
This would create a "ProjectOrderingService" that has a method called "MoveProject" that would take the project to move and would be responsible for loading all the projects, reorder them and save them using the ProjectRepository. I favor this approach since it seems like a perfect fit for a domain service. Members of my team don't like this since it requires the service to access repositories to retrieve and save the projects, but to me this is perfectly allowed since the implementation of the service would be in the infrastructure layer.
Which approach is most in line with DDD priciples, or is there another approach that is better suited to this need?
The most recommended best
Very impressive. Keep writing
Thank You for taking your
I was looking for crucial
When I read this post it
Cosmetics should be used
Thanks
rosetta stone
What a fantabulous post this
MBT shoe is anti-shoe,Factory
They provide controlled and
If you are nfl jerseys fans,
If you are nfl jerseys fans, don’t miss to buy cheap authentic NFL Jerseys here nfl store, 2010 new style nfl football jerseys on hot sale!
If you are nfl jerseys fans, don’t miss to buy cheap authentic NFL Jerseys here nfl store.
nothing is impossible.
Difficult question
This is nice post which I was
The blog was absolutely
cookware of china
COOKWARE
Keep up the good work. online
Thanks for sharing
For most couples who are
I like the river boat Home
how awful
We have the latest coach bags
other possibilities?
Does this integer value actually need to be a property in the domain entity? It sounds more like an implementation value rather than an instrinsic property of a "Project" (although I obviously do not know the domain). In which case two other possibilities could be:
1) Move responsibility to the "Project" entities repository where you can optimise the code that does the ordering into the repository implementation; define the methods you require in the repository interface to both re-order entities and fetch entities as an ordered list.
2) Have a new "OrderedProjectsCollection" entity. This could be more flexible in that you could create different ordered lists (but would need a different structure to your database).