Got confused while designing Aggregates

Question

I am designing an application, which will store sports statistics, show them in different diagrams and do few more operations on them. Allow user to do some mock drafts etc.

I choose to build a domain first, and then create a database via code-fist approach. So I have my entities:
- Player (name, teamId, list of stats)
- Team (name, list of players)
- Stats (beginDate, endDate, playerId, <...different stats in separate columns>...........)

How should I divide them into aggregates? I know Player is an aggregate. I know that List should be in Player aggregate. But what about the Team? Is the team part of Player aggregate or separate one?

I'm confused, cause Player definitely has to have foreign key to the Team. But the Team makes totally sense without a Player (not like Stats, which without a Player doesn't make sense at all - that's why they are part of Player aggregate). I could show statistics for Teams only.

Should the Team be separate aggregate?

EDIT: This is how my domain looks like:

public class Stats
{
    // Stats...
}

public class Player
{
    public Team Team { get; private set; }
    public List<Stats> Stats { get; private set; }
}

public class Team
{
    public string Name { get; private set; }
    public string FullName { get; private set; }
}

Answer 1

The important question to ask, when designing aggregates, is how does the data change?

For team to be an aggregate implies that it has some state, and even after that state changes it is still the same team. (ie, for team to be an aggregate, it must be an entity -- not merely a value type).

So in your model, do teams change in any interesting ways? By which I mean, in a way that your model cares about? Or are they simply an attribute of a player.

If teams are an entity, and you really care about things that team do (releasing players, acquiring players, and so on), then team should probably be an aggregate, and its state includes a collection of playerIds. (Note, in this model, you probably wouldn't include a teamId within the player aggregate).

On the other hand, if teams are just a property, then they can be a value type within the player aggregate.

That said, I've played in similar domains before -- here's what I do.

Player is an aggregate; but the state of a player is primarily biographical information. When it turns out that some player has been using a false birth certificate, the player aggregate is updated, but that doesn't change any of the relationships with the rest of the model.

Team is an aggregate. I'm currently using team as a collection of players, but that isn't quite right for what I am doing. In my world, the relationship between team and player has some time dependence. So there's some entity like "Contract", that defines the relationship between a player and a team over some time period (start date, end date). The contract is an entity in my model, because the end date of the players "current" contract isn't fixed.

The GameLog in my model is where stats appear. I don't need to worry about specific in game events; I just aggregate a player's performance at the end of a game to create a log entry.

So to get Team stats, I need to look at the contracts to figure out when each Player was playing for them, and use that information to find the appropriate game logs to pull, and then roll up the lot.

Also too: there's a little bit of care to be had, because the sporting events in the real world are not constrained by your domain model. You don't want to be rejecting "real world" data just because your model says that wasn't supposed to happen!

Don't over simplify -- part of the point of domain driven design is to listen carefully to what the ubiquitous language is telling you, and make sure that you are accurately modeling those concepts.