Моделирование агрегата с помощью Eloquent

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

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

Уди Дахан предлагает, чтобы мы никогда не создавали агрегированные корни напрямую, а вместо этого использовали фабричный метод из другого объекта для возврата нашего нового экземпляра:

 final   class   Author   extends   Eloquent 
 { 
     // snip… 

     /** * @param Title $title * @param Copy $copy * @return Post */ 
     public   function  draftPost ( Title  $title ,   Copy  $copy ) 
     { 
         return   new   Post ([ 
             'title'   =>  $title , 
             'copy'   =>  $copy , 
             'author_id'   =>  $this -> id ]); 
     } 
 } 

В этом примере мы принимаем совет Уди Дахана и используем фабричный метод в другом объекте для построения нашего Поста. Это позволяет нам использовать язык бизнеса для объяснения того, что автор готовит сообщение, но также позволяет нам применять инварианты, когда мы не могли этого сделать. Использование этого подхода при моделировании с помощью Active Record требует более мягких навыков для реализации и применения — поскольку мы не можем предотвратить непосредственное создание экземпляров объекта, команда должна знать «что и как» при создании агрегатов.

Другой альтернативой является использование именованного конструктора при создании нового экземпляра:

 final   class   Post 
 { 
     // snip… 

     /** * @param AuthorId $authorId * @param Title $title * @param Copy $copy * @return static */ 
     public   static   function  draft ( AuthorId  $authorId ,   Title  $title ,   Copy  $copy ) 
     { 
         return   new   Post ([ 
             'title'   =>  $title , 
             'copy'   =>  $copy , 
             'author_id'   =>  $authorId ]); 
     } 
 } 

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

Опять же, этот подход имеет существенный недостаток, когда мы рассматриваем наследование от Active Record ORM. Поскольку мы расширяем Eloquent, в графе объектов уже есть ряд статических методов. Не у всех концепций домена будут хорошие заголовки рабочего процесса, такие как «черновик». Часто наиболее подходящим названием метода для описания создания является просто «создать». К сожалению, в Eloquent уже есть статический метод create() .

Существуют и другие шаблоны творчества, которые могут помочь, если разделение ответственности за создание объектов имеет смысл в вашем контексте.

Отношения

Агрегаты позволяют нам рассматривать группу объектов как единое целое. В нашем примере пост может иметь много комментариев. Как мы можем написать код Eloquent?

 $post -> comments ()-> save ( $comment ); 

Конечно, это сделает работу, но есть проблема. Запрашивая у поста соответствующие комментарии, мы полностью обходим Aggregate Root. Все общение с Агрегатом должно проходить через Корень, чтобы обеспечить соблюдение правил ведения бизнеса. Бизнес сообщил нам, что «заблокированные записи нельзя комментировать», однако мы только что смогли сохранить новый комментарий для записи, не проверяя ее заблокированный статус.

Наш пример помещает эту логику в класс Post , где он инкапсулирует создание Comment вместе с проверкой заблокированного статуса:

 $post -> comment ( $message ); 

При таком подходе мы больше не пропускаем проблемы постоянства. Код вне объекта $post не должен явно вызывать save() как он уже был вызван внутри.

Вывод

Мы показали, что моделирование Агрегата с помощью Active Record возможно, но это сложно и имеет много подводных камней. Это может стать довольно грязным, если вы попытаетесь обработать активную запись как традиционный объект. Active Record касается исключительно данных, тогда как объекты демонстрируют поведение и скрывают данные. Мы принципиально неправильно используем шаблон Active Record — и лучшее, что мы можем сделать, — это добавить поведение в структуру данных.

Эта статья не пытается сказать, что Active Record — это плохо, и при этом это не призыв к тому, чтобы всегда использовать его. Это просто инструмент, который мы можем использовать в зависимости от ситуации. Active Record — отличный инструмент для фокусировки на RAD, однако в некоторых ситуациях он просто не подходит. Я думаю, что из-за количества обсуждаемых компромиссов, моделирующие агрегаты подпадают под последнюю.

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

Кто прав? Вековой ответ на все вопросы: это зависит.