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
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