DDD и различие между объектом и объектом значения.Выбор совокупного корня - PullRequest
Новая
       34

DDD и различие между объектом и объектом значения.Выбор совокупного корня

1 голос
/ 21 марта 2010

Я дизайн и ЭМИ. Я определил центральным объектом для домена является Patient. Пациент должен иметь следующие данные Doctor и медицинские карты. Медицинские документы - это групповой термин, относящийся к коллективу «Встречи, лаборатории, рентген, рецепты» ...

Я новичок в DDD, и у меня возникли проблемы с парой концепций и моим пониманием DDD. Ниже приведен пример кода, который показывает класс Encounter. Encounter содержит пару свойств и также ссылается на другой класс Vitals.

Vitals не имеет значения вне Patient. Я все еще идентифицирую жизненно важные органы в базе данных с ее собственным ключом. Я не уверен, что это квалифицирует Vitals как сущность. В настоящее время у меня Vitals в качестве объекта значения.

Во-вторых, при построении моей модели Encounter определен как корень Aggregate. Через Encounter доктор мог заказать лаборатории, рентген и назначить лекарство. В основном Encounter документирует причину, по которой такие предметы заказываются.

Существует проблема в том смысле, что мне также нужно было бы получить эти элементы вне контекста Encounter, поэтому это означает, что Encounter не является Совокупным корнем. Элемент типа Vitals - это просто объект значения.

Это мой код ... 

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(); }
    }
}

1 Ответ

1 голос
/ 21 марта 2010

Я не совсем уверен в вашем актуальном вопросе . Отсутствие вопросительных знаков делает это немного сложным для понимания - однако я постараюсь ответить на то, что казалось вопросом.

Медицинские карты, врачи и пациенты - это потенциально совокупные корни по отношению к чему-либо: все они существуют в реальном мире, вы даже можете прикоснуться к ним, и каждый из них «объединяет» другие объекты или фрагменты информации. Однако вам может не потребоваться моделировать объекты в той степени, в которой они фактически становятся совокупными корнями - это зависит от точных требований вашего приложения.

Однако эти объекты не агрегируют друг друга. Врачи могут существовать без медицинской документации, как и пациенты. Жаль, что в медицинских записях нуждаются оба доктора и , поэтому они не могут быть агрегированы ни одним из них. Таким образом, они становятся сущностью.

Каждый из вышеупомянутых должен иметь свою индивидуальность. Обратите внимание, что эти объекты живут, даже если их связанные элементы не. Совершенно очевидно, что врач остается в системе, даже если пациент этого не делает, но, что более важно, документы также сохраняются (и могут помешать удалению как пациентов, так и врачей, но это другая проблема).

Я все еще идентифицирую жизненно важные органы в базе данных с помощью своего собственного ключа

В конце концов, вам нужно хранить список жизненно важных органов для каждого пациента. Поскольку вы, вероятно, используете SQL, вы, вероятно, захотите смоделировать это отношение m: n с помощью таблицы компоновщика, поэтому вам придется назначить ключ. Все в порядке. Это недостаток персистентного уровня, а не модели, но вы должны убедиться, что никогда не используете этот ключ ни для чего, кроме внутренних целей приложения.

поэтому это означает, что Encounter не является совокупным корнем

«Встреча», безусловно, не является совокупным корнем по отношению к врачам или пациентам: это опять-таки отношение m: n, на этот раз между врачами и пациентами, поэтому, очевидно, будет много встреч на пациента и на доктора. Если одна из встреч была удалена (например, потому что они были неправильными), это не привело бы к удалению пациента или врача. Кроме того, Encounter не является совокупным корнем для рецепта: рентген, например, является чем-то, что само по себе имеет смысл. Тем не менее, вы можете сохранить ссылку. Опять же, удаление Encounter в будущем не вернет рентгеновский снимок.

Встречи не имеют врачей или пациентов. Так же как и врачи «своих» встреч.

Также обратите внимание, что встреча может привести к назначению лекарства или не привести ни к чему.

ПРИМЕЧАНИЕ Ваш метод AddBP() эффективно удалит старое значение, поэтому оно не должно называться add. Что еще более важно, этот метод делает класс Vital изменчивым и, следовательно, намного более сложным. Я бы избавился от этого метода.

...