Как решить, должен ли один объект быть частью совокупности или нет

Question

После того, как я начал читать о DDD и агрегатах, я, кажется, пытаюсь вписать все в агрегаты. Не особенно помогает то, что почти в каждом сообщении в блоге, учебнике и т. Д. Используется один и тот же пример: Order and orderlines.

Что означает, что объект может жить сам по себе или нет? Означает ли это, что он не может жить самостоятельно в моем моделировании домена, или это означает, что он не живет сам по себе в реальном мире?

Я делаю приложение, в котором пользователь может отслеживать свое вождение. Как, продолжительность, расстояние и т. Д.

Я создал StudentDriver класс для моделирования человека, DrivingLog для моделирования "книги" и DrivingRecords для моделирования каждой "строки" / записи, которую пользователь делает, когда он / она проехал. Это содержит продолжительность, расстояние и так далее.

Итак, теперь возникает вопрос: следует ли рассматривать StudentDriver как совокупный корень всех этих классов, и каждое действие проходит через StudentDriver? Или StudentDriver должен быть корнем, а DrivingLog - другим корнем, и тогда StudentDriver и DrivingLog будут иметь связь между собой?

Было бы приятно услышать, как вы решили это? И в этом примере, и в целом.

Answer 1

DDD была отличной книгой, и мне также нравилось читать то, что Эванс говорил о совокупной структуре.Я думаю, что вы, возможно, слишком далеко зашли.

Насколько я понимаю, цель совокупного шаблона:

Когда каждая часть программы взаимодействует с любой другой частьюстановится трудным для понимания (и отладки), потому что вы не можете понять какую-либо отдельную часть;чтобы понять какую-то одну часть, вы должны понимать все.

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

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

Это полезная идея, чтобы иметь в своем концептуальном «наборе инструментов», но вам не нужноиспользовать это только ради этого.Вместо того, чтобы беспокоиться о том, что означает «объект может жить самостоятельно», посмотрите, что вы на самом деле хотите сделать с StudentDriver s и DrivingLog s, и подумайте:

Будет ли этот кодпроще и более управляемым, если я позволю другим классам напрямую работать с DrivingLog s или если я требую, чтобы они вызывали методы на StudentDriver для извлечения или изменения этих данных?Представьте, как код будет читаться в любом случае.В одном случае вы могли бы писать drivingLog.mileage() из "внешних" классов;в другом вы бы написали studentDriver.loggedMileage().

Одним из лучших моментов, сделанных DDD, была важность соответствия модели и реализации, которая даже включает такие вещи, как выбор идентификаторов (в вашем коде), которые имеют смыслв реальном выражении.В соответствии с этим, вы также можете посмотреть на операции, которые выполняет ваш код, и подумать: если я думаю о том, что эта операция представляет в реальном выражении, это то, что делается с драйверами или с журналами?Если на самом деле операция выполняется для журналов, не используйте методы StudentDriver, которые делегируют DrivingLog, просто потому, что вы хотите использовать шаблон Aggregate.

Answer 2

Агрегация - это отношения между двумя классами, которые имеют отношение полностью / частично. Например. Автомобиль цельный и колесо это его часть.

В вашем случае вы можете сделать StudentDriver владельцем DrivingLog, если он принадлежит ему. Если бы не было существующего студента, не было бы смысла вести DrivingLog. Таким образом, DrivingLog не может существовать сам по себе.

StudentDriver должен быть пользователем root и знать о DrivingLog. Но DrivingLog не должен знать о StudentDriver (так же, как однонаправленная ассоциация)