DDD referencing child of aggregate root?

Question

I am trying to learn DDD. I am modeling a property management domain and I think I have two contexts (subdomains?): a property management context and a resident context.

Let's say I have an aggregate root Apartment, that holds Floorplans and Units. Each Apartment can have many Floorplans, and each Floorplan can have many Units.

public class Apartment : IAggregateRoot // for clarity
{
    public int Id { get; }
    public Address Address { get; set; }
    public ICollection<Floorplan> Floorplans { get; set; }
}

public class Floorplan
{
    public int Id { get; }
    public int ApartmentId { get; set; }
    public string Name { get; set; }
    public int Bedrooms { get; set; }
    public int Bathrooms { get; set; }
    public ICollection<Unit> Units { get; set; }
}

public class Unit
{
    public int Id { get; }
    public int FloorplanId { get; set; }
    public string Number { get; set; }
}

Let's say in the property management context I now introduce a Resident who gets assigned to a Unit. My Unit and Resident class now looks like this:

public class Unit
{
    public int Id { get; }
    public int FloorplanId { get; set; }
    public string Number { get; set; }
    public ICollection<Resident> Residents { get; set; }
}

public class Resident // in the property management context
{
    public int Id { get; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public void UpdateBalance(...);
}

My question is now if I introduce a Resident in the resident context (that can PayRent() or UpdateProfile(), etc) they must be have a 1:1 relationship with Resident in the property management context, but I thought I cannot reference a non-aggregate root entity without going all the way through Apartment because a Resident cannot exist without an Apartment.

Is my understanding of aggregate roots incorrect? Is Resident an aggregate root in both contexts? I'm not sure how that would be modeled.

Answer 1

The most critical piece of information a practitioner of DDD needs to understand and, frankly, the biggest stumbling block I see here in this tag, is that DDD is about modeling the functional requirements of a system. That is, DDD asks us to take a perspective that focuses on the behaviors of our system and let the data that supports these behaviors become an implementation detail.

In your question above I see lots of "this has that", and not a lot of "this does that". I don't mean to say that your model is necessarily incorrect, rather, that you are approaching your system in a way that leads to exactly the problem you have outlined above. When you only focus on the data within a system (I'm guessing your domain model closely resembles your physical model) it almost always leads to "overlapping" concerns.

In this case we should partition our Resident vertically according to behavior (though sharing an ID). Ask yourself, Why does Resident in the Property Management Context need to have FirstName and LastName fields? Are these pieces of data consequential in terms of the use cases present within the context? Does UpdateBalance or RentUnit require a name? Probably not. On the other hand, the Resident in your Resident Context does need these fields if it is to be made responsible for updating this information.

And to be clear, a Resident (that is an entity with FirstName and LastName fields) can absolutely exist without an apartment. I'm sitting right here. Always be on the lookout for artificial constraints. I may not be renting from you (yet!), but that shouldn't prevent your system from knowing of my existence. Maybe Person or Customer is a better name than Resident in this case (as the latter carries an implication with it).

To summarize, your model requires two entities (Person and Resident) in two contexts (Resident and Property Management) that share an identifier from your persistent data store - each responsible for carrying-out and enforcing the particular behaviors relevant to their existence (updating different fields). Whether these map to the same physical database table is an implementation detail.