DDD and distinction between Entity and Value object. Choosing the aggregate root

Question

I am design and EMR. I have determined the central object to the domain is the Patient. The patient must have the following a Doctor and Medical Records. Medical Records is a grouping term refering to the collective of Encounters, Labs, XRays, Prescriptions.... I am new to DDD and I am having trouble with a couple of concepts and my understanding of DDD. Below is a code sample which shows and Encounter class. Ecounter contains a couple of propertiees and it also references another class Vitals. Vitals has no significance outside of the Patient. I still identify vitals in the database with its own key. I am not sure if that qualifies Vitals as being an entity. Currently I have Vitals has a Value object. Second the way my model is built I have Encounter defined as and Aggregate root. Through and Encounter a doctor could order labs, xrays and prescribe medicine. Basically the Ecounter documents the reason why such items are being ordered/ The problem exist in the sense that I would also need to retrieve these items outside the context of an Encounter, therfore does that mean Encounter is not an Aggregate Root. An item such as Vitals is that just a value object. Code is below

//Abbreviated class listing public class Encounter {

String ChiefComplaint {get; set;} string Plan {get; set;} string Assessment {get; set;} Vital PatientVital {get; set;} }

public class Vital { public float Temperature { get; private set; } public BloodPressure BP { get; private set; } public int Pulse { get; private set; } public int Respiratory { get; private set; }

    internal Vital(float temperature, int systolic, int diastolic, int pulse, int respiratory)
    {
        this.Temperature = temperature;
        BloodPressure bp = new BloodPressure();
        bp.Systolic = systolic;
        bp.Diastolic = diastolic;
        this.Respiratory = respiratory;
        this.BP = bp;
    }

    public void AddBP(int systolic, int diastolic)
    {
        BloodPressure bp = new BloodPressure();
        bp.Systolic = systolic;
        bp.Diastolic = diastolic;
        this.BP = bp;
    }

}

public struct BloodPressure
{

public BloodPressure(int systolic, int diastolic) { Systolic = systolic; Diastolic = diastolic; }

    public int Systolic { get; private set; }
    public int Diastolic { get; private set; }
    public string bloodPressure
    {
        get { return this.Systolic.ToString() + "/" + this.Diastolic.ToString(); }
    }
}

Answer 1

I am not entirely sure about your actual question. The lack of question marks makes that a bit hard to understand - I will try to respond what seemed the question, however.

Medical Records, Doctors and Patients are all potentially aggregate roots with respect to something: They all exist in the real world, you can even touch them and each of them 'aggregate' other objects or pieces of information. However, you might not need to model objects to the degree where they actually become aggregate roots - that depends on the exact requirements of your application.

These entities do not aggregate each other, however. Doctors can exist without medical records and so do patients. The pity is that medical records need both patients and doctors so they cannot be aggregated by either one. Thus, they become an Entity.

Each of the beforementioned must have their own identity. Note that these objects live on even if their associated items don't. Most obviously, the doctor stays in the system even if the patient does not, but more importantly, the documents also live on (and might keep both patients and doctors from being deleted, but that is another issue).

I still identify vitals in the database with its own key

After all, you need to store a list of Vitals for each patient. Since you are probably using SQL, you'll probably want to model this m:n relation using a linker table, so you'll have to assign a key. That is OK. It's a shortcoming of the persistence layer, not of the model, but you should make sure never to use this key for anything but internal application purposes.

therfore does that mean Encounter is not an Aggregate Root

An "Encounter" is certainly not an aggregate root with respect to doctors or patients: It's again an m:n relation, this time between doctors and patients, so obviously there will be many encounters per patient and per doctor. If one of the encounters was deleted (because they were incorrect, for example) this would not delete the patient or the doctor. Also, an Encounter is not an aggregate root for a prescription: An X-Ray, for example, is something that makes perfect sense on its own. However, you might want to keep a reference. Again, deleting the Encounter in the future won't revert the X-Ray.

Encounters don't own doctors or patients. Neither do doctors 'own' encounters.

Also note that an encounter might lead to medicine being prescribed, or might not lead to anything.

NOTE Your method AddBP() will effectively delete the old value, so it should not be named 'add'. More importantly, this method makes the Vital class mutable and thus much more complicated. I'd get rid of that method.