Этот вопрос проверяет знакомство с продвинутыми архитектурными подходами, которые помогают строить сложные бизнес-ориентированные системы.
DDD (Domain-Driven Design) — это подход к разработке сложных систем, который фокусируется на бизнес-логике и языке предметной области. Гексагональная архитектура (или "Порты и адаптеры") — это архитектурный стиль, который реализует принципы DDD. Она организует приложение так, чтобы его ядро (бизнес-логика) не зависело от внешних вещей (как БД или API). Вместо этого ядро определяет "порты" (интерфейсы), а "адаптеры" реализуют подключение к реальным технологиям.
Это два взаимосвязанных понятия, которые помогают справляться со сложностью бизнес-логики в больших приложениях.
DDD — это набор принципов и паттернов для проектирования программного обеспечения, которое тесно связано с бизнес-доменом (предметной областью).
Универсальный язык (Ubiquitous Language):
Единый язык для общения разработчиков и экспертов предметной области. Термины из бизнеса (например, "Заказ-наряд", "Складской остаток") становятся классами и методами в коде.
Ограниченный контекст (Bounded Context):
Разделение большой системы на отдельные, четко ограниченные модули, каждый со своей моделью и своим универсальным языком.
Пример: В контексте "Доставка" сущность Order имеет атрибуты address и delivery_time, а в контексте "Оплата" — amount и payment_status.
Строительные блоки (Tactical Design):
Сущность (Entity): Объект, имеющий идентичность, которая сохраняется на протяжении всего жизненного цикла (например, User с id).
Объект-значение (Value Object): Неизменяемый объект, не имеющий идентичности, описываемый своими атрибутами (например, Money с amount и currency).
Агрегат (Aggregate): Кластер связанных объектов, которые treated как единое целое для изменения данных. Имеет корень (Aggregate Root).
Сервис домена (Domain Service): Логика, которая не умещается в рамки одной сущности или значения.
Это архитектурный паттерн, который помещает бизнес-логику в "центр" приложения, изолируя ее от внешних деталей.
Ядро (Domain Layer):
Содержит сущности, объекты-значения, сервисы домена — всю бизнес-логику.
Абсолютно чистое: Не содержит ссылок на базы данных, фреймворки, API и т.д.
Порты (Ports):
Это интерфейсы, объявленные в ядре. Они определяют, что должно делаться.
Пример: OrderRepositoryInterface (порт) с методом save(Order $order).
Адаптеры (Adapters):
Это реализации портов, расположенные "снаружи" ядра. Они определяют, как это делается с помощью конкретной технологии.
Пример: DoctrineOrderRepository (адаптер) реализует OrderRepositoryInterface и сохраняет заказ в PostgreSQL через Doctrine ORM.
Тестируемость: Ядро можно тестировать юнит-тестами, подменяя адаптеры на заглушки (Mocks).
Независимость от технологий: Можно легко сменить базу данных, веб-фреймворк или внешний сервис, просто написав новый адаптер, не трогая бизнес-логику.
Фокус на бизнесе: Разработчики вынуждены сначала думать о бизнес-правилах, а не о технологиях.
Вывод: DDD и Гексагональная архитектура — это мощные, но сложные подходы. Их стоит применять в больших проектах со сложной и постоянно меняющейся бизнес-логикой, где выгоды от поддерживаемости и гибкости перевешивают накладные расходы на сложность. Для простых CRUD-приложений они будут избыточны.
