Все самое полезное для пхпшника в одном канале.
По рекламе: @tproger_sales_bot
Учиться у нас: clc.to/M561SQ
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/67a5d13cd6fa92100ee6f68b
Post #5458
2.66K
Богатые и анемичные сущности в PHP с Doctrine: как правильно структурировать бизнес-логику
Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.
Анемичные сущности:
🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.
🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.
🔸 Этот подход часто используется в приложениях с преобладанием операций CRUD, но может привести к дублированию кода и хрупким архитектурам.
Богатые сущности:
🔹 Богатые сущности инкапсулируют как состояние, так и поведение. Они содержат бизнес-логику внутри самой сущности, что делает код более поддерживаемым, выразительным и легким для тестирования.
🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.
🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).
Преимущества богатых сущностей:
🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.
🔸 Лучшая читаемость кода: API сущности отражает домен (например,
🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.
Статические методы create():
В статье рекомендуется использовать статические методы
Сервисный слой против логики сущности:
🔹 Часто бизнес-логику переносят в сервисный слой (например,
🔹 Напротив, богатые сущности включают бизнес-логику прямо внутри себя, что снижает зависимость от внешних сервисов и делает систему более связанной.
Когда использовать богатые и когда анемичные сущности:
Богатые сущности идеальны для приложений с сложными бизнес-правилами, которые нужно соблюдать, а также для создания ясной и выразительной доменной модели.
Анемичные сущности могут быть полезны в простых приложениях CRUD или в средах, где бизнес-логика минимальна.
👉 Читать статью
Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.
Анемичные сущности:
🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.
🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.
🔸 Этот подход часто используется в приложениях с преобладанием операций CRUD, но может привести к дублированию кода и хрупким архитектурам.
Богатые сущности:
🔹 Богатые сущности инкапсулируют как состояние, так и поведение. Они содержат бизнес-логику внутри самой сущности, что делает код более поддерживаемым, выразительным и легким для тестирования.
🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.
🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).
Преимущества богатых сущностей:
🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.
🔸 Лучшая читаемость кода: API сущности отражает домен (например,
$order->pay() вместо $orderService->payOrder()), что делает код более понятным и легче воспринимаемым.🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.
Статические методы create():
В статье рекомендуется использовать статические методы
create() для создания сущностей, чтобы гарантировать их создание в валидном состоянии. Это позволяет избежать создания неполных или некорректных объектов и концентрирует логику инициализации в одном месте.Сервисный слой против логики сущности:
🔹 Часто бизнес-логику переносят в сервисный слой (например,
OrderPaymentService), но это может привести к слабой инкапсуляции и дублированию кода.🔹 Напротив, богатые сущности включают бизнес-логику прямо внутри себя, что снижает зависимость от внешних сервисов и делает систему более связанной.
Когда использовать богатые и когда анемичные сущности:
Богатые сущности идеальны для приложений с сложными бизнес-правилами, которые нужно соблюдать, а также для создания ясной и выразительной доменной модели.
Анемичные сущности могут быть полезны в простых приложениях CRUD или в средах, где бизнес-логика минимальна.
👉 Читать статью
- 🤔 7
- 👍 4
- ❤ 3
