Modify a property of an aggregate's entity

Question

Suppose I have a house-lending service, like Airbnb. I have a House entity, which can have a name. There's also the Reservation entity, which has a start date, an end date, and a name (which isn't needed but it's to ask the question).

The business rule would be then that no two reservations can overlap. So my aggregate root would be the House and Reservation would belong to that aggregate. This allows me iterate over the reservations when there's a new one and verify there's no overlap. Here, the concept of aggregates and bounded context makes perfect sense to me.

However, what if I need to update the Reservation's name? If I need to update the House name I can do it via the aggregate, which still bothers me since I have to load all the reservations only to change a name. But for the Reservation's case, I can't figure out a "DDD-y" way to do it. If I go directly to the reservation entity, I'm breaking the bounded context. Likewise, if I go through the aggregate, I'm loading the house and all the other reservations only to change one reservation's name.

How is this case handled with DDD? Should I actually have a Reservation entity with only the parameters needed to check availability, and another, say ReservationName through which I change its name? If so, do I need a new persistence object for it (i.e., a repository or a mapper)?

This is an issue I've wondered about for a couple of years, and everytime I run into it I solve it with less than ideal ways (like going to Reservation directly).

Answer 1

You are correct in that you have more than two entities here. The problem (as you have already laid out) is that House needs to "own" it's Reservation collection in order to enforce the invariant regarding overlapping date ranges, but there is a whole bunch of data that comes along for the ride.

The "DDD-y" solution, of course, is to model the behavior of your system and let the data supporting that behavior become and implementation detail. I'd bet dollars to doughnuts that the design of the above system started as a 2 (maybe 3) database tables that were then translated into objects. This approach is backwards (and often leads to problems like the above).

It's perfectly fine (and often desirable) to partition your data vertically such that some fields ([start_date], [end_date], [occupant_no]) are mapped into one object (Reservation), while others ([name], [contact_email]) are mapped into another (ReservationDetails) despite being sourced from the same database table. Normalization boundaries rarely superimpose directly onto vectors of change!