Путаница с сущностями и совокупными корнями для пациентов, стоматологов, лечения и истории болезни

Question

Я новичок в DDD и решил попрактиковаться в этом с системой зубного клини c, которую я разрабатываю, но я изо всех сил пытаюсь смоделировать домен, поэтому дополнительная пара глаз будет высоко оценена. Для этой системы стоматологии эксперт в области сказал мне, что пациент имеет только одну историю болезни. История болезни должна иметь номер записи, который является уникальным в системе. История болезни содержит стоматологическое лечение, которое пациент мог пройти (например, запланированное лечение), а также лечение, которое пациент уже проходил. Каждое лечение имеет свою цену, и поэтому история болезни содержит общую цену (на основе запланированных / примененных процедур). Всякий раз, когда пациент получает лечение, он / она должен будет заплатить по меньшей мере 50% от этой стоимости лечения, то есть он / она в конечном итоге заплатит остальную часть суммы на будущих встречах (если плана лечения не существует, он / она будет придется заплатить за 100% цены). Наконец, это стоматологическое клини c дает возможность пациентам платить в разных валютах, потому что иногда пациент, приходящий на этот день, имеет только евро, но затем он решает, что ему нужен план, и в будущем он будет платить по фунтам *. 1001 *

Исходя из всего этого и моего начального знания DDD, я в первую очередь думаю, что у меня есть следующие сущности:

• Пациент
• Лечение
• Стоматолог

У меня будет несколько ценностных объектов, но наиболее важными могут быть:

• Деньги (для цен и валюты)
• Подпись (для примененного лечения)
• Зуб или Зубы (используется для объекта «Лечение»)

И я могу найти только один агрегат, который является историей болезни, поскольку он собирает информацию о пациенте, а также лечение (плановое и прикладное). Но это будет означать, что всякий раз, когда я обновляю историю болезни, мне придется обновлять информацию о пациенте и лечение, даже если один из них никогда не менялся. Пациенты могут изменить свою личную информацию, которая будет отражена в истории болезни, но это не влияет на лечение.

Я немного запутался в том, как смоделировать это. Пожалуйста, помогите!

Answer 1

Помните, что агрегаты и, как следствие, ограниченный контекст (B C), представляют собой группу данных и бизнес-логи c, которые принадлежат друг другу (и, скорее всего, вещи, которые необходимо изменить транзакционно). Данные, которые содержит агрегат, присутствуют потому, что они нужны бизнес-логике c, а не потому, что это нужно некоторым экранам приложений. Это очень важно, чтобы устранить некоторую путаницу и освободить вас от некоторых ограничений для проектирования ваших агрегатов.

Например, когда вы отображаете историю болезни для пользователя, вы можете указать имя пациента, адрес, возраст и т. Д., А также цены на лечение, но если вы подумаете об этом, вы не Мне не нужно ничего из этого, чтобы управлять историей болезни. Из того, что вы говорите, в истории болезни есть номер записи, идентификатор пациента и список идентификаторов лечения, возможно, с датами, когда они были сделаны.

Если вы хотите отобразить историю болезни для пользователя, вы можете использовать UI Composition. Итак, вы получаете историю болезни (которая в основном представляет собой набор идентификаторов и дат). Затем из PatientId истории болезни вы можете получить информацию о пациентах из B C, которому она принадлежит. С помощью «Идентификаций лечения» вы можете получить описания процедур от какого-либо B C, которому он принадлежит, и их цены от B C, к которому они принадлежат.

Таким образом, исходя из этого, вы можете строить свои агрегаты не на основе «соответствующих имен» в вашем домене, таких как «Пациент», «Лечение» или «Стоматолог», а на основе бизнес-логики c, которую они реализуют.

Это просто дикие догадки, но я могу думать о:

B C Маркетинг (из-за отсутствия лучшего названия): Содержит описания всех методов лечения, информацию о стоматологах, Информация о номерах и материалах и др. c. Итак, тексты, фотографии и другие детали.

B C Финансы: содержит информацию о ценах на каждое лечение, платежные записи каждого платежа, кредиты и дебеты каждого пациента и т. Д. c. Отвечает за отслеживание всех этих вещей. Например, он может знать, когда лечение начинается / заканчивается и, в зависимости от истории болезни пациента, требует 50 или 100% оплаты. Здесь нет необходимости иметь прямое отношение к истории болезни, нужно только знать, является ли это первым лечением или нет.

B C Планирование: отвечает за планирование новых процедур и отслеживание их начала и окончания sh. Это может содержать историю или потенциально может быть где-то еще, если это необходимо.

B C Медицина: отвечает за ведение всех медицинских карт, аллергий, медицинских данных о состоянии зубов и т. Д. c.

B C Уход за пациентами: отвечает за отслеживание информации о пациентах, имени, национальности, контактных данных и т. Д. c.

Когда у вас есть представление об ограниченном контексте, вы можете определить агрегаты. Может быть один или несколько на B C. Кроме того, некоторые вещи могут не быть совокупными. Например, история болезни может не требовать фактической совокупности, если это, в основном, запись идентификаторов лечения и дат, в которые они были сделаны, и нет связанных бизнес-логи c (история не собирается отрицать лечение, есть мнения о том, когда лечение должно произойти и так далее, это просто история).

Не воспринимайте это как рекомендуемый дизайн, а просто как мыслительный процесс, чтобы придумать собственное решение.

Answer 2

У сущностей есть Id, где как у объектов-ценностей есть структурная идентичность, что означает, что если два объекта-значения имеют одинаковое значение, то они одинаковы.

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

Вы не описали роль и атрибуты Зуба и Подписи.

В случае Зуба имеет значение, чей это Зуб? Можете ли вы заменить зуб пациента другим зубом с такими же характеристиками? Если это имеет значение, то Зубу требуется идентификатор, следовательно, это сущность.

В случае подписи, как вы собираетесь сравнивать две подписи? Есть ли у вас программное обеспечение для распознавания изображений, которое может сравнить внешний вид двух подписей и решить, что они одинаковы? У вас могут быть два пациента с похожими подписями, следует ли считать, что их подпись одинакова?

Если вы выбираете историю болезни в качестве совокупности, то вы должны рассматривать ее как один объект. Вы хотите загрузить всю историю болезни, чтобы добавить к ней новое лечение? Может ли лечение быть связано с другой организацией, такой как стоматолог? Если вы можете использовать часть истории болезни (например, «Лечение») по отдельности, то она не является совокупной.

Несколько хороших учебников:

1. Сущность против объекта-значения от Владимира Хорикова
2. Сущности, Ценные объекты, агрегаты и корни Джимми Богард