Aggregate roots depend on the use case so does that mean that we might end up with really a lots of repositories?_问答_开发者

Ive heard a lots that aggregate roots depend on the use case. But what does that mean in coding context ?

You have a service class which offcourse hold methods (use cases) that gonna accomplish something in a repository. Great, so you use a repository which is equal to an aggregate root to perform your querying.

Now you need to perform some other kind of operation which use totally different use case than the first service class but use the same entities.

Here the representation :

Entities: Customer, Orders, LineOrder

Service 1: Add new customers, Delete some customers, retrieve customer orders

Here the aggregate root seem to be Customer because you need this repository to perform thoses use cases.

Service 2: Retrieve customer from an actual order

Here the aggregate root seem to be Order because you need this repository to perform this use case.

If i am wrong please correct me. Now that mean you have 2 aggregates roots.

Now my question is, since aggregate roots depend on the use case does that mean that we might end up with really a lots of repositories if you end up having lots of use cases ?

The above example was probably not the best example... so lets say we have a Journal which hold JournalEntries which each entries hold Tasks, Problems and Notes. (This is in the cont开发者_如何学编程ext of telling to a system what have been done to a project)

Does that mean that im gonna end up with 2 repository ? (Journal, JournalEntry) In the use cases where i need to add new tasks, problems and notes from an journal entry ? (Can be seen as a service)

Or might end up with 4 repository. (Journal, Task, Problems, Notes) In the use cases where i need to access directment task, problems and notes ? (Can be seen as another service)

But that would mean if i need both of theses services (that actually hold the use cases) that i actually need 5 repository to be able to perform use cases in both of them ?

Thanks.

Hi I saw your post and thought I may give you my opion. First I must say I've been doing DDD in project for three years now, so I'm not an expert. But I'm currently working in a project as an architect an coaching developers in DDD, and I must say it isn't a walk in the park... I don't know how many times I've refactored the model and Entity relationships.

But my experience is that you endup with some repositories (more than few but not many). My Aggregates usually contains a few classes and the Aggregate object graph isn't that deep (if you know what I mean).

But I try to be concrete:

1) Aggregate roots are defined by your needs. I mean if you feel that you need that Tasks object through Journal to often, then maybe thats a sign for it to be upgraded as a aggregate root.

2) But everything cannot be aggregate roots, so try to capsulate object that are tight related. Notes seems like a candidate for being own by a root object. You'd probably always relate Notes to the root or it loses its context. Notes cannot live by itself.

3) Remember that Aggregates are used for splitting up large complex domains into smaller "islands" that take care of thier inhabbitants. Its important to not make your domain more complex than it is.

4) You don't know how your model look likes before you've reached far into the project implementation phase. If you realize that some repositories aren't used that much, they may be candidates for merging into other root object (if they have that kind of relationship). You can break out objects that are used so much through root object without its context. I mean for example if Journal are aggregate root and contains Notes and Tasks. After a while you model grows and maybe Tasks have assoications to Action and ActionHistory and User and Rule and Permission. Now I just throw out a bunch om common objects in a rule/action/user permission functionality. Maybe this result in usecases that approach Tasks from another angle, "View all Tasks performed by this User" etc. Tasks get more involved in some kind of State/Workflow engine and therefor candidates for being an aggregate root itself.

Okey. Not the best example but it maybe gives you the idea. A root object can contain children where some of its children can also be root object because we need it in another context (than journal). But I have myself banged my head against the wall everytime you startup with a fresh model. Just go with the flow and let the model evolve itself through its clients/subsribers. You refine the model through its usage. The Services (application services and not domain services) are of course extended with methods that respond to UI and usecases (often one-to-one).

I hope I helped you in someway...or not :D

Yes, you would most likely end up with 5 repositories (Journal, JournalEntry, Task, Problems, Notes). Your services would then use these repositories to perform CRUD for each type of entity.

Your reaction of "wow so many repositories" is not uncommon for developers new to DDD.

However, your repositories are usually light weight assuming your model and DB schema are fairly evenly matched which is often the case. If you use an ORM such as nHibernate or a tool such as codesmith generator then it gets even easier to create your repositories.

At first you need to define what is aggregate. I don't know about use case aggregates. I know about aggregates following...
Aggregates are union of several entities. One of the entities is the aggregate root, the rest entities (or value types) have sense only in selected aggregate root context.
For example you can define Order and OrderLine as an aggregate if you don't need to do any independent actions with OrderLine entities. It means that OrderLine makes sense in Order context only. Why to define aggregates at all? It is required to reduce references between objects. That will simplify you domain model.
And of course you don't need to have OrderLineRepository if OrderLine is a part of Order aggregate. Here is a link with more information. You can read Eric Evans DDD book. He explains aggregates very well.