Внедрение предметно-ориентированного проектирования в PHP
Перевод статьи
Как использовать PHP для управления следующим DDD-проектом вашей компании и эффективно моделировать реальные ситуации, чтобы помочь определить вашу бизнес-логику?
Предметно-ориентированное проектирование (Domain-Driven Design, в дальнейшем - DDD) – это методология разработки программного обеспечения для проектирования сложных программных проектов с целью доставки конечного продукта, который отвечает задачам организации. Фактически, DDD способствует фокусированию проекта на развивающейся базовой модели.
Что такое модель предметной области?
На мой взгляд, модель предметной области (Domain Model) – это ваше восприятие контекста, к которому она относится. Попробую объяснить подробнее. «Область» сама по себе означает мир бизнеса, с которым вы работаете, и задачи, которые он предназначен решить. Например, если вы хотите разработать приложение для онлайн-доставки еды, в вашей предметной области всё (задачи, бизнес-правила и т. д.) будет об онлайн-доставке еды, что необходимо реализовать в вашем проекте. Модель предметной области – ваше структурированное решение задачи. Она должна представлять собой словарь и ключевые понятия задач из предметной области.Единый язык
«Единый язык» («Ubiquitous Language») – это язык, используемый бизнес-специалистами для описания модели предметной области. Это означает, что команда разработчиков последовательно использует этот язык во всех взаимодействиях и в коде. Язык должен основываться на модели области. Позвольте мне привести пример:$product = new Entity\Product();
$product->setTitle(new Title('Mobile Phone'));
$product->setPrice(new Price('1000'));
$this->em->persist($product);
$this->em->flush();
//add is a static method in product class
$product = Product::add(
new Title('Mobile Phone'),
new Price('1000')
);
Многослойная архитектура
В этой статье я не собираюсь говорить об объектно-ориентированном проектировании. Но DDD предполагает основы хорошего проектирования. Эрик Эванс (Eric Evans - автор книги «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем») считает, что разработка хорошей модели предметной области – это искусство. Чтобы разработать хорошую модель предметной области, вам нужно знать о разработке, управляемой моделями (Model-Driven Design). Model-Driven Design – объединение модели и реализации. Многослойная архитектура является одним из её блоков. Многослойная архитектура (Layered Architecture) – идея изоляции каждой части, основанная на многолетнем опыте и сотрудничестве разработчиков. Слои перечислены ниже:- Пользовательский интерфейс
- Уровень приложения
- Уровень домена
- Уровень инфраструктуры
Объекты-значения и сущности
Я большой поклонник объектов-значений (Value Objects). Я думаю, что они – суть ООП. Хотя объекты-значения DDD кажутся простыми, они являются серьезным источником замешательства для многих, включая меня. Я читал и слышал очень много разных способов описания объектов-значений с разных точек зрения. К счастью, каждое из разных объяснений, скорее помогло мне углубить понимание объектов-значений, нежели противоречило друг с другом. Объекты-значения доступны по их значению, а не по идентификатору. Это неизменяемые объекты. Их значения не изменяются (или изменяются, но редко) и не имеют жизненного цикла (это означает, что они не как строки таблиц баз данных, которые можно удалить), например, валюты, даты, страны и т. д. Вы можете создавать объекты-значения, которые вы не распознаете как объекты-значений. Например, адрес электронной почты может быть строкой или это может быть объект-значение с собственным набором поведений. Код, расположенный ниже, демонстрирует пример класса объекта-значения:final class ImagesTypeValueObject
{
private $imageType;
private $validImageType = ['JPEG', 'GIF', 'BMP', 'TIFF', 'PNG']; public function __construct($imageType)
{
Assertion::inArray($this->validImageType, $imageType, 'Sorry The entry is wrong please enter valid image type');
$this->imageType = $imageType;
}
public function __toString()
{
return $this->imageType;
}
}
Агрегаты
Модель может содержать большое количество объектов предметной области. Независимо от того, сколько всего мы предусмотрим при моделировании области, часто бывает, что многие объекты зависят друг от друга, создавая набор отношений, и вы не можете быть уверены в результате на 100%. Другими словами, вы должны знать о бизнес-правиле, которое всегда должно соблюдаться в вашей модели предметной области; только с этими знаниями вы можете с уверенностью рассуждать о своем коде. Агрегаты помогают уменьшить количество двунаправленных ассоциаций между объектами в системе, потому что вам разрешено хранить ссылки только на корень. Это значительно упрощает проектирование и уменьшает количество слепых изменений в графе объектов. С другой стороны, агрегаты помогают с развязкой больших структур, устанавливая правила отношений между сущностями. (Примечание: агрегаты также могут иметь свойства, методы и инварианты, которые не вписываются в один класс) Эрик Эванс в своей книге установил некоторые правила для реализации агрегатов, и я перечисляю их ниже:- Корневой объект имеет глобальную идентичность и в конечном счете отвечает за проверку инвариантов.
- Корневые объекты имеют глобальную идентичность. Внутренние сущности имеют локальное идентичность, уникальную только внутри агрегата.
- Ничто вне границы агрегата не может содержать ссылку на что-либо внутри, кроме корневого объекта. Корневой объект может связывать ссылки с внутренними объектами на другие объекты, но эти объекты могут использовать их только временно и не могут быть привязаны к ссылке.
- В качестве следствия вышеприведенного правила, только базовые корни могут быть получены непосредственно с запросами базы данных. Все остальные объекты должны быть найдены путем обхода ассоциаций.
- Объекты внутри агрегата могут содержать ссылки на другие совокупные корни.
- Операция удаления должна удалять сразу все в пределах общей границы (со сборкой мусора это легко. Поскольку внешних ссылок на что-либо, кроме корня, нет, удалите корень и все остальное будет собрано).
- Когда совершено изменение какого-либо объекта на границе агрегата, все инварианты агрегата должны быть удовлетворены.
Фабрики
В мире ООП Фабрика является объектом, который отвечает только за создание других объектов. В DDD фабрики используются для инкапсуляции знаний, необходимых для создания объектов, и они особенно полезны для создания агрегатов. Корень агрегата, который предоставляет метод фабрики для создания экземпляров агрегата другого типа (или внутренних частей), будет нести основную ответственность за обеспечение его основного агрегирующего поведения, и метод фабрики является лишь одним из них. Фабрики также могут обеспечить важный уровень абстракции, который защищает клиента от зависимости от конкретного класса. Бывают случаи, когда фабрика не нужна, и простого конструктора достаточно. Используйте конструктор, когда:- Конструкция не сложная.
- Создание объекта не связано с созданием других, и все необходимые атрибуты передаются через конструктор.
- Разработчик заинтересован в реализации и, возможно, хочет выбрать стратегию для использования.
- Класс - тип. Нет иерархии, поэтому нет необходимости выбирать между списком конкретных реализаций.
Хранилища
Хранилище – это слой, который находится между доменом вашего проекта и базой данных. Мартин Фаулер (Martin Fowler) в своей книге «Шаблоны корпоративных приложений» пишет, что хранилище является промежуточным взаимодействие между доменом и слоем сопоставления данных с использованием интерфейса, подобного коллекции, для доступа к объектам домена. Это означает, что вы должны думать о доступе к данным в своей базе данных так же, как и к стандартным объектам коллекции.Позвольте мне объяснить немного подробнее
Представьте себе, что в DDD вам может понадобиться создать объект либо с помощью конструктора, либо с помощью фабрики; вы должны запросить его из корня агрегата. Проблема в том, что разработчик должен иметь ссылку на корень. Для больших приложений это становится проблемой, потому что необходимо убедиться, что разработчики всегда имеют ссылку на необходимый объект. Это приведет к созданию разработчиками ряда ассоциаций, которые на самом деле не нужны. Другая причина, по которой хранилища имеют большое значение, - это доступ к базе данных. Программист не должен знать детали, необходимые для доступа к ней. Поскольку база данных находится на уровне инфраструктуры, ей приходится иметь дело с большим количеством деталей инфраструктуры, а не с концепциями предметной области. Кроме того, если разработчик запрашивает запуск запроса, это приведет к раскрытию еще большего количества внутренних деталей необходимых запросу. Если у нас нет хранилища, фокус домена будет потерян, а дизайн будет скомпрометирован. Поэтому, если разработчики используют запросы для доступа к данным из БД или вытягивают несколько конкретных объектов, логика домена перемещается в запросы и код разработчика, поэтому агрегаты будут бесполезны. Наконец, хранилище выступает в качестве места хранения для объектов, доступных по всему миру. Хранилище также может включать в себя стратегию. Он может получить доступ к одному постоянному хранилищу или другому, основанному на указанной стратегии.Реализация в Laravel
Как вы уже могли знать, лучшим выбором для внедрения DDD в PHP является Doctrine ORM. Чтобы реализовать агрегаты и хранилища, нам нужно внести некоторые изменения в наши сущности и создать некоторые файлы на нашем доменном уровне. Я решил реализовать небольшую часть приложения, в котором пользователь может создать страницу или изменить ее. Каждая страница может содержать много комментариев, и каждый комментарий может содержать некоторые под-комментарии. Администраторы могут утверждать/отклонять комментарии после их добавления. В приведенном выше сценарии первым шагом является создание базового хранилища в доменном уровне, базовом хранилище, полученном из Doctrine EntityRepository, который позволит нам иметь все встроенные функции хранилища Doctrine. Здесь мы также можем использовать нашу общую функциональность, и все наши хранилища должны наследоваться от нее. Реализация выглядит следующим образом:namespace App\Domain\Repositories\Database\DoctrineORM;use App\Domain\Events\Doctrine\DoctrineEventSubscriber; use Doctrine\Common\Persistence\Event\LifecycleEventArgs; use Doctrine\ORM\EntityRepository; use Doctrine\ORM\Mapping\ClassMetadata; use Doctrine\ORM\EntityManager; use GeneratedHydrator\Configuration; use Doctrine\Common\Collections\ArrayCollection;
abstract class DoctrineBaseRepository extends EntityRepository { public $primaryKeyName; public $entityName = null;
public function __construct(EntityManager $em) { parent::__construct($em, new ClassMetadata($this->entityClass)); $this->primaryKeyName = $em->getClassMetadata($this->entityClass)->getSingleIdentifierFieldName(); } }
namespace App\Domain\Repositories\Database\DoctrineORM\Page; use App\Domain\User\Core\Model\Entities\Pages; use App\Domain\Repositories\Database\DoctrineORM\DoctrineBaseRepository;class DoctrinePageRepository extends DoctrineBaseRepository { private $entityClass = Pages::class;
public function AddComments($pages) { $this->_em->merge($pages); $this->_em->flush(); } }
namespace App\Domain\Interactions\Core\Model\Entities;use App\Domain\User\Comments\Model\Entities\Comments; use Doctrine\Common\Collections\ArrayCollection; use Doctrine\ORM\Mapping as ORM;
/** * Pages * * @ORM\Table(name="pages") * @ORM\Entity */ class Pages { /** * @var string * * @ORM\Column(name="page_title", type="string", length=150, nullable=false) */ private $pageTitle; /** * @ORM\OneToMany(targetEntity="App\Domain\User\Comments\Model\Entities\Comments", mappedBy="pageId", indexBy="pageId", cascade={"persist", "remove"}) */ private $pageComment; /** * @var integer * * @ORM\Column(name="page_id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private $pageId;
public function __construct() { $this->pageComment = new ArrayCollection(); }
/** * @param Comment * @return void */ public function addComments(Comments $comment) { $this->pageComment[] = $comment; } //... other setters and getters. }
namespace App\Domain\User\Comments\Model\Entities;
use Doctrine\ORM\Mapping as ORM;
/** * Comments * * @ORM\Table(name="comments") * @ORM\Entity */ class Comments { /** * @ORM\ManyToOne(targetEntity="App\Domain\User\Core\Model\Entities\Users") * @ORM\JoinColumn(name="users_user_id", referencedColumnName="id") */ private $usersUserId; /** * @ORM\ManyToOne(targetEntity="comments", inversedBy="children") * @ORM\JoinColumn(name="parent_id", referencedColumnName="comment_id") */ private $parentId; /** * @ORM\ManyToOne(targetEntity="App\Domain\Interactions\Core\Model\Entities\pages", inversedBy="pageComment" ) * @ORM\JoinColumn(name="page_id", referencedColumnName="page_id") */ private $pageId; /** * @ORM\OneToMany(targetEntity="comments", mappedBy="parent") */ private $children;
/** * @param Page * @return void */ public function __construct() { $this->children = new\Doctrine\Common\Collections\ArrayCollection(); } }
namespace App\Domain\Comment;use App\Domain\User\Comments\Model\Entities\Comments; use App\Domain\Repositories\Database\DoctrineORM\User\DoctrineCommentRepository; use App\Domain\Repositories\Database\DoctrineORM\Interactions\DoctrinePagesRepository; use Assert\Assertion;
class PageAggregate { public $Pages; public $pageResult; public $parentId = null; public $comments; public $DoctrineRepository = DoctrinePagesRepository::class;
public function __construct($id, $comments = null, $administrative = null) { $this->DoctrineRepository = \App::make($this->DoctrineRepository); Assertion::notNull($this->pageResult = $this->DoctrineRepository->findOneBy(['pageId' => $id]), 'sorry the valid page id is required here'); $commentFacory = new Commentfactory($this->pageResult, $comments); return $commentFacory->choisir($administrative); } }
namespace App\Domain\Comment;
interface CommentTypeFactoryInterface
{
public function confectionner();
}namespace App\Domain\Comment;
interface CommentFactoryInterface
{
public function choisir();
}
namespace App\Domain\Comment;use App\Application\Factory\Request\RequestFactory;
class Commentfactory implements CommentFactoryInterface { private $page; private $comment; private $parentId;
public function __construct($page, $comment = null) { $this->page = $page; $this->comment = $comment; }
public function choisir($administrative = null) { // TODO: Implement choisir() method. if (is_null($administrative)) { $comment = new Comment($this->page, $this->comment); return $comment->confectionner(); } $comment = new AdministrativeComments($this->page, $this->comment, $this->parentId); return $comment->confectionner(); } }
namespace App\Domain\Comment;use App\Domain\User\Comments\Model\Entities\Comments; use App\Domain\Repositories\Database\DoctrineORM\User\DoctrineCommentRepository; use App\Domain\Repositories\Database\DoctrineORM\Interactions\DoctrinePagesRepository; use App\Domain\Interactions\Core\Model\Entities\Pages; use App\Application\Factory\Request\RequestFactory; use Assert\Assertion;
class Comment implements CommentTypeFactoryInterface { private $page; private $comments; public $DoctrineCommentRepository = DoctrineCommentRepository::class; public $DoctrineRepository = DoctrinePagesRepository::class;
public function __construct(Pages $page, $comment) { $this->page = $page; $this->comments = $comment; $this->DoctrineCommentRepository = \App::make($this->DoctrineCommentRepository); $this->DoctrineRepository = \App::make($this->DoctrineRepository); }
public function confectionner() { if (is_array($this->comments)) { \Request::replace($this->comments['data']); \App::make(RequestFactory::class); $this->addComments(); } elseif (is_null($this->comments)) { return $this->retrieveComments(); } elseif (is_int($this->comments)) { $this->deleteComment(); } return true; }
private function addComments() { if (isset($this->comments['id']) && !is_null($this->comments['object'] = $this->DoctrineCommentRepository->findOneBy(['commentId' => $this->comments['id']]))) { return $this->editComment(); } $this->comments = $this->CommentObjectMapper(new Comments(), $this->comments['data']); $this->page->addComments($this->comments); $this->DoctrineRepository->AddComments($this->page); }
private function editComment() { $comment = $this->CommentObjectMapper($this->comments['object'], $this->comments['data']); $this->page->addComments($comment); $this->DoctrineRepository->AddComments($this->page); }
private function deleteComment() { $this->DoctrineCommentRepository->delComments($this->comments); }
private function retrieveComments() { return $this->page->getPageComment(); } //... }
namespace App\Domain\Comment;use App\Domain\Interactions\Core\Model\Entities\Pages; use App\Domain\Repositories\Database\DoctrineORM\User\DoctrineCommentRepository; use App\Domain\Repositories\Database\DoctrineORM\Interactions\DoctrinePagesRepository; use App\Domain\User\Comments; use Assert\Assertion;
class AdministrativeComments implements CommentTypeFactoryInterface { private $page; private $comments; private $parentId; private $privilege; public $DoctrineCommentRepository = DoctrineCommentRepository::class; public $DoctrineRepository = DoctrinePagesRepository::class;
public function __construct(Pages $page, $comment, $parentId) { $this->page = $page; $this->comments = $comment; $this->parentId = $parentId; $this->privilege = new Athurization(\Auth::gaurd('admin')->user()); }
public function confectionner() { $action = $this->comments['action']; Assertion::notNull($this->comments = $this->DoctrineCommentRepository->findOneBy(['commentId' => $this->comments['id']]), 'no Valid comment Id'); $this->$action; return true; }
public function approve() { $this->privilege->isAuthorize(__METHOD__); $this->DoctrineCommentRepository->approve($this->comments, \Auth::gaurd('admin')->user()); }
public function reject() { $this->privilege->isAuthorize(__METHOD__); $this->DoctrineCommentRepository->reject($this->comments, \Auth::gaurd('admin')->user()); }
public function delete() { $this->privilege->isAuthorize(__METHOD__); $this->DoctrineCommentRepository->delete($this->comments, \Auth::gaurd('admin')->user()); } }
