ardalis / pluralsight-ddd-fundamentals

Sample code for the Pluralsight DDD Fundamentals course by Julie Lerman and Steve "ardalis" Smith

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Makes sense to get rid of Action scheduleHandler?

Haukinger opened this issue · comments

It's unclear to me why the Schedule and Appointment entities rely on the consumer (i.e. the Create and Update endpoints) to maintain their invariants, namely appointments that overlap and share a patient/room/doctor have IsPotentiallyConflicting set to true, all others have it set to false (and `

Of course, in the example with only one schedule it's rather esoteric to expect the consumer to pass the wrong handler to UpdateStartTime or UpdateAppointmentType or to forget calling AddNewAppointment, but it would be easy to eliminate the risk once and for all by giving Appointment a property that holds its Schedule and is set from the constructor (by exchanging Guid scheduleId for Schedule schedule). If that property is kept private, the consumer cannot abuse it to do schedule-things through the appointment, while entity framework will still populate it when querying for the appointment.

Wild guess at the rationale: older versions of entity framework couldn't deal with private properties, and you didn't want to burden the repository with manually assigning the Schedule to the Appointment.

The general guidance I've been following for years is, navigation properties only flow in one direction from the aggregate root to its children. Children then only have id references back to the aggregate root. The origins of this guidance were in fact at least in part due to common limitations with both ORM and Serialization libraries that would often blow up or otherwise misbehave if loops were present in the object graph (such as Schedule -> Appointment -> Schedule).

That said, while I still think it helps simplify aggregate generally, if you find that it's beneficial to include a navigation property in a child back to the parent, and there are no negative consequences in your app from doing so, then by all means do it. It's probably something I should revisit with the latest versions of .NET and EF Core, too, and see if the reasons for the original guidance are less relevant now.