Почему так много архитектур компонента

Луковая, гексагональная, чистая, порты и адаптеры, слои DDD, трёхзвенная — при всём разнообразии слоистых архитектур принципиально можно выделить две: трёхзвенную и доменно-центричную (domain-centric architecture).

В трёхзвенной архитектуре слой презентации обращается к слою бизнес-логики, а слой бизнес-логики — к слою доступа к данным. Таким образом, бизнес-логика зависит от способа хранения данных. В доменно-центричной архитектуре нижним слоем является слой бизнес-логики, тогда как инфраструктурный слой вместе со слоем презентации располагаются над ним.

(рисунок)

Когда мы говорим, что слой A располагается выше слоя B, это означает, что A знает интерфейс B и может обращаться к нему. Например, если бизнес-логика содержит операцию оплаты товара, выраженную в виде Java-метода pay, то HTTP-контроллер, располагающийся обычно в слое презентации, знает её и обращается к ней.

Разницу между двумя архитектурами хорошо показывает использование JPA. JPA является технологией доступа к данным. В трёхзвенной архитектуре слой бизнес-логики зависит от слоя доступа к данным, поэтому использование JPA-аннотаций на классах сущностей предметной области, расположенных в слое бизнес-логики, является совершенно естественным. В противоположность этому, в доменно-центричной архитектуре JPA-аннотации в слое бизнес-логики невозможны по определению, поскольку здесь бизнес-логика не зависит от слоя доступа к данным. Для доменно-центричной архитектуры более естественным будет конфигурирование ORM-маппинга через внешние XML-файлы.

Поскольку бизнес-логика оказывается окружена остальными слоями, доменно-центричные архитектуры принято изображать в виде концентрических колец.

(рисунок)

Если архитектур принципиально две, почему тогда существует столько названий? Каждая из них фокусируется на определённом наборе вопросов и по-своему детализирует общую схему.

К примеру, гексагональная архитектура (она же — архитектура портов и адаптеров), предложенная Кокбёрном, фокусируется на взаимодействии приложения с внешним миром. Здесь неважно, с чем именно взаимодействует приложение: с пользователем, базой данных или другой системой — во всех случаях это взаимодействие реализуется через порт и адаптер.

Тогда как гексагональная архитектура пытается универсализировать принцип, луковая архитектура, наоборот, детализирует зоны ответственности. Во внешнее кольцо, помимо слоя презентации и слоя доступа к данным, помещается слой тестов, а слой бизнес-логики разбивается на три слоя: слой доменной модели, слой доменных сервисов и слой сервисов приложения.

Чистая архитектура похожа на архитектуру портов и адаптеров, но подробнее разделяет внешнюю часть на интерфейсные адаптеры и фреймворки с драйверами.

В DDD-архитектуре фокус смещён на домен, поэтому она детализирует устройство слоя бизнес-логики, разделяя его на доменный слой и слой приложения.