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.

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.

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.