Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.
Анемичные сущности:
🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.
🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.
🔸 Этот подход часто используется в приложениях с преобладанием операций CRUD, но может привести к дублированию кода и хрупким архитектурам.
Богатые сущности:
🔹 Богатые сущности инкапсулируют как состояние, так и поведение. Они содержат бизнес-логику внутри самой сущности, что делает код более поддерживаемым, выразительным и легким для тестирования.
🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.
🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).
Преимущества богатых сущностей:
🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.
🔸 Лучшая читаемость кода: API сущности отражает домен (например,
$order->pay() вместо $orderService->payOrder()), что делает код более понятным и легче воспринимаемым.🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.
Статические методы create():
В статье рекомендуется использовать статические методы
create() для создания сущностей, чтобы гарантировать их создание в валидном состоянии. Это позволяет избежать создания неполных или некорректных объектов и концентрирует логику инициализации в одном месте.Сервисный слой против логики сущности:
🔹 Часто бизнес-логику переносят в сервисный слой (например,
OrderPaymentService), но это может привести к слабой инкапсуляции и дублированию кода.🔹 Напротив, богатые сущности включают бизнес-логику прямо внутри себя, что снижает зависимость от внешних сервисов и делает систему более связанной.
Когда использовать богатые и когда анемичные сущности:
Богатые сущности идеальны для приложений с сложными бизнес-правилами, которые нужно соблюдать, а также для создания ясной и выразительной доменной модели.
Анемичные сущности могут быть полезны в простых приложениях CRUD или в средах, где бизнес-логика минимальна.
👉 Читать статью