В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени. Для меня, одним из обязательных требований, к "чистой" архитектуре, является грамотное разделение кода приложения по слоям. Сам слой не делает ничего, вся соль в том, как он используется и какие ограничения накладываются на компоненты, ему принадлежащие. Давайте немного пофилософствуем, перед тем как рассмотреть конеретные практические приемы. Вы, конечно же, пишите тесты. Грамотная спроектирвоанная система слоёв, невероятно упрощает тестирование. Различные типы тестов подходят для кода из разных слоев. Назначения каждого теста становится более очевидным. Набор тестов в целом становится более стабильным и более быстроработающим. Однако, у нас есть паникёр из твиттера:

ООП версия спагетти кода — это код лазанья, с переизбытком слоев. Лично я никогда не встречал код-лазанью, зато видел очень много лапшекода. Правда бывало, что я писал код, в котором допускал серьезные архитектурные ошибки, и неверно разделял приложение на слои, что приносило некоторые проблемы. В этой статье я описываю, как мне кажется, наилучший набор слоев, большая часть из которых описана в книге Vaughn Vernon "Implementing Domain-Driven Design"(ссылка ниже). Прошу заметить, что слои не имеют жесткой привязки к DDD, хотя они и дают возможность создавать чистые доменные модели, при соответсвующем желании у разработчика. Внутри src/ у меня есть директории для каждого контекста(Bounded Context), например который я выделяю в своем приложении. Каждая из них также служит корневым неймспейсом для принадлежащих ей классов. Внутри каждого контекста я создаю директории для каждого из слоёв: Кратко опишу каждый из них. Доменный слой содержит классы для известных DDD типов/паттернов: Внутри папки Domain я создаю подпапку Model, внутри неё — директории для каждого из агрегата(Aggregate root). Папка с агрегатом содержит все связанные с ним штуки(объекты-значения, доменные события, интерфейсы репозиториев и т.д) Обратите внимание, что код из доменного слоя никак не соприкасается с реальным миром. И если бы не тесты, то никто не мог бы обращаться к его объектам напрмяую(это делается через верхние слои). Тесты для доменной модели должны быть исключительно модульными. Т.к доменный слой не взаимодетсвует напрямую с файловой системой, сетью, бд и т.д, то мы получаем стабильные, независимые, чистые и быстрые тесты. Прикладной слой(Application Layer) содержит классы команд и их обработчиков. Команда представляет собой указание на что-то, что должно быть выполненно.Это обычный DTO(Data Transfer Object), содержащий только примитивные значения. Всегда должен быть обработчик команды, который знает, как нужно выполнить конкретную команду. Обычно обработчик команды (также его называют application service) ответственен за все необходимые взаимодействия — использует данные из команды для создания(или извлечения из базы) агрегата, выполняет над ним какие то операции, может сохранить агрегат после этого. Код этого слоя также можно покрыть юнит тестами, однако на этом этапе можно начинать писать и приёмочные. Вот хорошая статья на эту тему Modelling by Example от Константина Кудряшова. Код, написанный в предыдущем слое, тоже не вызываается никем кроме тестов. И только после добавления инфраструктурного слоя, приложение становится рельно пригодным к использованию. Инфраструктурный слой содержит код, необходимый для взаимодействия приложения с реальным миром — пользователями и внешними сервисами. Например, слой может содержать код для: Код этого слоя надо покрывать интеграционными тестами(в терминологии Freeman and Pryce). Здесь вы тестируете всё по настоящему — настоящая база, настоящий вендорский код, настоящие внешние сервисы. Это возволяет убедиться в работоспособности тех вещей, которые не находятся под вашим контролем но используюся в вашем приложении. Все фреймворки и бибилотеки взаимодействующие с внешнем миром(файловой системой, сетью или базой) должны вызываться в инфраструктурном слое. Конечно, код домена и прикладного слоя часто нуждается в функциональности ORM, HTTP клиента и т.д. Но он должен использовать её только через более абстрактные зависимости. Как того и требует правило зависимостей. Правило зависимостей(сформулированное Robert C. Martin в The Clean Architecture) утвержадет, что на каждом слое приложения вы должны зависеть только от кода текущего или более глубокого слоя. Это значит, что код домена зависит только от себя, код слоя приложения от своего кода или домена, а код инфраструктурного слоя может зависеть от всего. Следуя этому правилу, нельзя сделать в доменном слое зависимость на код из инфрастуруктурного. Но слепо следовать какому-либо правилу, непонимая в чем его истинный смысл — это довольно глупая затея. Так почему же вы должны использовать правило зависимостей? Следуя этому правилу вы гарантируете, что чистый код слоёв прикладного и доменного слоев не будет завязан на "грязный", нестабильный и непредсказуемый код инфраструктуры. Также, применяя правило зависимостей, вы можете заменить что угодно в инфраструктурном слое не прикасаясь и не изменяя код более губоких слоёв, что даёт нам богатые возможности для ротации и переносимости компонентов. Этот способ уменьшения связанности модулей известен давно, как Dependency Inversion Principle — буква "D" в SOLID сформулированном Робертом Мартиным: "Код должен зависеть от абстракций, не от реализаций". Практическая реализация в большинстве ооп языков заключается в выделинии публичного интерфейса для всех вещей, от которых вы можете зависеть(интерфейс и будет абстракцией) и создании класса, реализующего этот интерфейс. Этот класс будет содержать детали, не имеющие значения для интерфейса, следовательно этот класс и будет реализацией, о которой говориться в inversion principle. Применяя предложенный набор слоёв вместе с правилом зависимостей, можно получить много плюшек при разработке: Все это выглядит крайне заманчиво: мне нравится возможность беспроблемной замены компонентов приложения + я люблю принимать важные архитектруные решения не перед стартом проекта(основываясь на своем прошлом опыте и догадках), а тогда, когда начинают проясняться реальные кейсы использования разных частей приложения, и я имею возможность выбирать подходящие решения исходя из существующих потребностей. Как упомяналось ранее, этот вариант расслоения приложения, хорошо уживается с любым фреймворком, т.к его место четко определено в инфраструктурном слое. Некоторое считают, что в моём варианте "слишком много слоев". Я не понимаю, как можно считать 3 слоя, слишком большим количеством, но если вас это смущает то можете убрать прикладной. Вы потеряете возможность писать приемочные тесты(они станут чем то похожи на системные — более медленные и хрупкие) и не сможете тестировать один и тот же функционал вызываемый к примеру из веб-интерфейса и консольной команды без дублирования кода. В любом случае, вы сильно улучшите архитектуру вашего проекта благодаря раделению бизнесс логики и инфраструктурной части. Осталось более подробно рассмотреть инфраструктурный слой. Так мы плавно перейдем к теме гексагональной архитектуры(порты и адаптеры). Но всё это, в следующей части. Также можно ознакомиться с Deptrac — инструмент, помогающий соблюдать правила использования слоев и зависиомостей. TeamLead | Backend Developer