DDD: Адрес как совокупный корень? - PullRequest
Новая
       36

DDD: Адрес как совокупный корень?

4 голосов
/ 14 июля 2010

Я изо всех сил пытаюсь разработать эту систему, в которой адрес является наиболее важной частью информации. Теперь в этом случае адрес - это не просто несколько строк строк. Мы храним муниципалитеты (код, название), район (почтовый индекс, название), улицы (код, название), номер дома на улице в определенном районе, принадлежащем муниципалитету. Это очень нормализованная схема.

Итак, у нас есть объекты Municipal, District, Street и HouseNumber, каждый из которых имеет отношения друг к другу, определяя полный адрес для человека (или чего-то еще).

Теперь я пытаюсь выяснить, имеет ли смысл иметь совокупный корень с именем Address? Объект Address (совокупный корень) будет иметь ссылки на HouseNumber, Street, District и Municipal. Тогда человек будет связан с адресом.

Строго говоря, этот агрегатный корень не нужен, но если у меня его нет, мне придется пройти через многие объекты, чтобы получить полный адрес. Имеет ли смысл создавать агрегированный корень на основе этого аргумента?

В этом случае человек никогда не будет ссылаться ни на что, кроме совокупного корня, однако пользовательский интерфейс может отображать только муниципалитеты (при просмотре адресов и т. Д.). Является ли это нарушением идеи совокупного корня?

Мне бы очень хотелось получить ваш совет и заняться этой проблемой. Любая помощь будет высоко ценится!

Небольшое обновление из другого обсуждения моей проблемы:

В агрегате необходимо управлять некоторыми инвариантами. Например; я не может иметь номер дома на улице, которая находится в одном районе / муниципалитете, где почтовый ящик находится в другом другом районе / муниципалитете. Так что при назначении почтовый ящик на адрес / лицо, мне нужно убедиться, что они находятся в одном район.

Также существуют некоторые границы согласованности (если я понял это понятие, правильно). Если у меня есть адрес, это должен быть номер дома в округе на улица (в этом районе). Улица может охватывать несколько районов, поэтому важно убедиться, что номер дома на этой улице находится в правильном район.

Обновление о проектировании агрегата:

Номер дома фактически является точкой входа для адреса. Номер дома связан с улицей и районом. Таким образом, человек связан с номером дома. Я также хочу определить, есть ли у человека «почтовая ответственность» за этот номер дома. Введение совокупного корневого адреса заставляет человека связываться с ним вместо номера дома. В базе данных совокупный адрес будет содержать связь 1-1 с номером дома, а адрес имеет 1- * для человека. Где я должен хранить значение, указывающее, что лицо несет почтовую ответственность или нет? Должен ли я сделать это в совокупности адресов? Или где бы ты положил это? И то же самое относится и к моим сущностям - где я должен указать, несет ли человек почтовую ответственность?

Ответы [ 3 ]

8 голосов
/ 14 июля 2010

Чтобы отличить, является ли адрес ценным объектом или сущностью, задайте себе вопрос - если адрес человека изменится, а у второго человека будет один и тот же адрес - изменится ли оба?Если они оба меняются - адрес повышается до сущности (причина в том, что идентичность адреса важна, а не имеет значение).

Чтобы отличить, является ли адрес сущностью или совокупным корнем, задайте себе вопрос - имеет ли адрес какой-то смыслсобственный или всегда привязанный к человеку, модифицируется через него, удаляется вместе с ним?Если он не связан с человеком, но существует сам по себе (в модели, которую вы моделируете, а не в реальности), тогда адрес является агрегированным корнем.

Строго говоря, этот агрегированный корень не нужен,но если у меня его нет, мне придется пройти через многие объекты, чтобы получить полный адрес.Имеет ли смысл создавать агрегированный корень на основе этого аргумента?

Нет, это не так.Технические проблемы не должны связываться с Вашим доменом.Субъект может работать как «субагрегат», адрес может объединять муниципалитет, город и т. Д. И при этом оставаться просто сущностью (потому что это не имеет смысла без человека).

Человекв этом случае никогда не будет ссылаться на что-либо, кроме сводного корня, однако пользовательский интерфейс может отображать только муниципалитеты (при просмотре адресов и т. д.).Является ли это нарушением общей идеи корня?

Презентация также не должна портить Ваш домен.Насколько я вижу - это прекрасно, если вы показываете только список сущностей и скрываете агрегаты, к которым они принадлежат.

Два человека могут быть связаны с одним и тем же адресом, и если один изони перемещаются, другой не перемещается автоматически.

Вопрос в том, как вы хотите смоделировать этот процесс перемещения?

Я вижу 2 способа:

  1. Когда человек # 1 перемещается, адрес изменяется , но адрес человека # 2 не является тем же адресом и, следовательно, - не затрагивается.В этом случае - адрес просто сущность.
  2. Когда человек # 1 перемещается, процесс перемещения переключает адрес на другой.В этом случае - адрес является агрегированным корнем.

Адреса существуют самостоятельно, и если человек переходит на адрес, он связывается с ним.

Это означает, что Вы хотите придерживаться 2-го пути (когда адрес является совокупным корнем).Это нормально, и в этом нет ничего плохого, но вам следует еще раз проверить, можно ли перевести адрес в соответствие с сущностью, что сделает вашу модель домена менее сложной.

И имейте в виду - нет "Модель ", есть только" Модель ".Вы не можете смоделировать реальность так, чтобы она идеально имитировалась. Вы можете смоделировать лишь часть ее, чтобы решить конкретные проблемы .

Вот почему так сложно отвечать на вопросы, связанные с DDD.
Никто не знает Ваши проблемы, которые вы пытаетесь решить.

Если я правильно понимаю (http://msdn.microsoft.com/en-us/magazine/dd419654.aspx - часть об агрегатах), то может ли адрес существовать безчеловек (или другой адресат) не имеет значения;вопрос в том, могут ли составные части адреса существовать или быть доступными без адреса.Если они могут, Адрес не должен быть объединенным корнем.

Это актуально.Если адрес не может существовать без человека (что здесь не так) - он неизбежно понижается в качестве сущности (потому что без человека это не имеет смысла) или объекта значения (если сам адрес не имеет идентичности).В противном случае - вы просто вводите ненужный агрегатный корень.

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

1 голос
/ 14 июля 2010

Агрегат, на мой взгляд, должен быть создан, если

  1. есть защитная оболочка отношения с его ассоциированным объекты
  2. объекты Агрегаты хранятся в базе данных, и только рут должен быть можно получить с помощью запросов. другие объекты должны быть получены через сквозные ассоциации.
  3. и у вас есть инвариантные правила, которые необходимо обеспечить единообразно для всех содержащихся объектов

ваш сценарий, кажется, не удовлетворяет ни одному из этих 2. так что мое мнение не

Также прочитайте этот пост и предоставили ответы: DDD: Совокупные корни

0 голосов
/ 14 июля 2010

Вопрос о том, должен ли Address быть отдельным объектом, не должен зависеть от технических проблем.

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

Тот факт, что Адрес сохраняется даже тогда, когда он не привязан к Person или другому классу, также указывает на то, что он должен быть его собственной сущностью.

Более того: Адрес может использоваться не только какЧеловек, но с помощью других вещей (классов), а также.Вы действительно хотите обременять каждый класс, у которого может быть адрес, чтобы иметь дело с тем, как сформировать его из составляющих его частей?

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

Обновление

Если я правильно понимаю (http://msdn.microsoft.com/en-us/magazine/dd419654.aspx - часть об агрегатах), то будет лиадрес может существовать без лица (или другого адресата) не имеет значения;вопрос в том, могут ли составные части адреса существовать или быть доступными без адреса.Если они могут, Адрес не должен быть объединенным корнем.

С одной стороны, Адрес должен быть совокупностью его составных частей.Но составные части адреса кажутся независимыми от адреса и могут существовать без него.В конце концов, муниципалитет или улица могут существовать без присутствия «двери».Итак, я бы сказал, что это дисквалифицирует Address как совокупный корень в терминах DDD.

Обновление Как упоминал Томми (см. Комментарии): лучшим вопросом будет «Будет ли система когда-либо манипулироватьулица / муниципалитет напрямую, или это всегда будет полный адрес? "

Я бы посчитал, что выбор муниципалитета из списка для построения адреса не является" прямой манипуляцией ", когда это всегда делается вконтекст построения адреса.Точно так же я бы не стал поддерживать этот список муниципалитетов «прямыми манипуляциями», если он ведется только для использования по адресу.

Обновление Как указывает Арнис, может ли Адрес существовать независимо отПерсона (или другая сущность) имеет значение в той степени, в которой это определяет, является ли Address сущностью в своем собственном праве.Насколько я понимаю, только корни могут быть только сущностями.

...