Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am in a big dilemma here.

I have a League, Team and Player entities. I have created a repo for the league only as a Team cannot exists without a League. At first I had bounded the players only with the team but then I realised I would have a problem with free agents so I also bounded the players to the league. Then I was wondering if a player could exists without a League or a Team and I am totally confused to that question.

So would you make a player repository or include them in the league repo?


share|improve this question
up vote 1 down vote accepted

You have to setup rules by yourself before modeling. Here are some suggestions

  • A team can exist without a League. How else would they be able to play matches outside the league?
  • Players can switch teams.
  • Players do not suddenly disappear if a team is shut down.

It all depends on how your application works. If you need to reference an aggregate outside the root (without the root) it usually means that that aggregate should be a root to.

share|improve this answer
Thanks, it is much clearer now – mateoc Oct 24 '12 at 16:31

Aggregate doesn't mean "cannot exists without". It means the two are logically tied together, and root manages access to entities inside the aggregate. In your case, I don't think League and Team are aggregate. Same with League and Player.

share|improve this answer
Nice, I have been thought that way, guess it enlighten me on aggregate. – mateoc Oct 24 '12 at 16:32

I think you are thinking to complex. What you have here are all related entities. These are all in the same layer and have all the same intention: handling of data.

Think about the usage of the Layer Supertype Pattern from Martin Fowler. It says:

It's not uncommon for all the objects in a layer to have methods you don't want to have duplicated throughout the system. You can move all of this behavior into a common Layer Supertype.

There you should have for example a EntityBase class. A abstract class that handles all the common things like ID, Validation, comparision.

Each of your items are entities and should have a own repository. If you do not want that a specified repository has posibility for write actions, you could split your IRepository interface into two parts: IReadOnlyRepository and IRepository.

For your example: You can have multiple leagues, a league has multiple teams and a team can have only 1 league?!?. Each team has multiple players, and they can only be part of one team. Nevertheless. It all depends on the informations you want to reuse. But for a good DB Design you should have each of this entities as own aggregates.

share|improve this answer
I don't think entity base classes have anything to do with the op's question – Jimmy Hoffa Oct 20 '12 at 14:29
This is also one of the most horribly-abused software patterns out there. Composition is usually a saner choice than inheritance. Inheritance means X is a Y but that has no meaning in the context of something like validation or comparison. Use interfaces or metadata to designate something as being comparable or needing validation. And storing the ID in a base class is often dangerous; not every entity is necessarily going to have the same ID type. This is why the most popular frameworks (like Hibernate/NHibernate) are the ones that don't impose base classes, and work on PO*Os. – Aaronaught Oct 21 '12 at 0:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.