DDD с объектами, которые содержат слишком много информации - PullRequest
Новая
       16

DDD с объектами, которые содержат слишком много информации

1 голос
/ 08 октября 2019

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

Примите во внимание следующее:

  • A School имеет 30 свойств, включая временные ряды учителей, которые работали там и когдаи временной ряд принципалов. Он также имеет временной ряд Classroom
  • A Classroom имеет еще 20 свойств. Кроме того, временной ряд цвета классной комнаты на протяжении лет, стиль расположения мест и т. Д. Он также имеет StudentAttendance История записей (временной ряд 30 лет)
  • A StudentAttendance запись имеет Year и NumberOfStudents (ValueObject)

Как вы определяете эту модель? Первоначально я думал, что Школа - это АР, так как классные комнаты не могут существовать без школы, а StudentAttendance не может существовать без классной комнаты.

Мой вопрос: чтобы изменить случайную StudentAttendance запись NumberOfStudents (скажем, в SchoolId 10, в классе 1 в 1993 году было 25 учеников вместо 30), нужно ли мне создать действительный School первый? Это означало бы, что мне нужно получить огромное количество информации для заполнения всех других свойств, которые не нужны для моих действий. Мне просто нужен школьный идентификатор, классный номер, год и новый номер.

В старом мире CRUD я бы просто определил методUpdateStudentAttenance(int schoolId, int classroomId, int year, int newNumberOfStudents)

Примечание. Согласно DDD, я создал классы с конструкторами, которые заполняют все свойства, чтобы создать и сохранить их в допустимом состоянии (например, School должен иметь Name, Area, ConstructionYear и т. д.), поэтому я не могу просто позвонить new School(id: 5)

1 Ответ

1 голос
/ 09 октября 2019

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

, т. Е.:

Вы определяете 3 сущности продукта. Один на складе BC, один в маркетинге BC и один в магазине BC. Так как Warehouse BC имеет только доменные действия, связанные с инвентаризацией, предоставлением, транспортировкой и т. Д .;сущность Product для Warehouse не нуждается в свойстве Customer Price.

, а не только в нескольких одинаковых вещах (Entity, VO или AG) в разных BC. Вы также можете иметь те же доменные понятия (школа, классная комната и т. Д.), Которые играют разные роли в каждом БК, в котором они участвуют. Школа может быть сущностью в одном BC, совокупным корнем в другом BC и VO в третьем BC. И у каждого есть своя собственная реализация со своими ограничениями, методами, свойствами и т. Д.

Лучший способ разработки с использованием DDD - это думать о действиях в домене. Весь ваш домианский дизайн должен ориентироваться на действия с доменом и информацию, необходимую для выполнения этих действий.

Также обратите внимание, что если у вас нет рабочего процесса с четким намерением в вашей системе (т.е. просто обновление NumberOfStudentsчтобы исправить ошибку и не иметь побочных эффектов) вам не нужен DDD, вам просто нужен CRUD, и нет ничего плохого в том, что DDD находится в одной части системы, а CRUD - в другой.

Этот ответ также может бытьпомощь в разработке: Агрегат или организация без бизнес-атрибутов

...