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

Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура - это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке.

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

Раньше мы в 3 частях [1, 2, 3] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

Дисклеймер

Это очень горячая тема для обсуждения: по разные стороны баррикад мы видим фанатов «Чистой архитектуры», DDD, функциональщиков, ООПшников, реактивщиков и поклонников иных взглядов на то, как, в итоге, должна выглядеть кодовая база. Предвкушая определенный негатив в комментах, я вынужден предостеречь читателя: мне не известны достаточно убедительные доказательства того, что тот или иной подход в проектировании приложения как‑то надежно коррелирует со стоимостью разработки, стабильностью или еще чем‑то важным. В отличие от архитектуры систем, тут я видел лишь пространные рассуждения и исследования из разряда «бабка надвое сказала». Так что вряд ли можно сказать, что структура приложения прям однозначно очень важна, а потому рекомендую не воспринимать все сказанное ниже близко к сердцу.

Есть все основания полагать, что, если вы не облажались с топологией команд и не сэкономили на автотестах, то все у вас будет, скорее всего, в порядке. Современные кодовые базы обычно настолько небольшие, что, кажется, можно выбрать ну вообще любой архитектурный подход по душе и он, вероятнее всего, почти никак и ни на что не повлияет. Ну, кроме вашего душевного равновесия, что, конечно же, тоже очень важно.

Что в меню

Попробуем вкратце разобрать основные идеи последних лет 70. Заодно, рассмотрим основные архитектурные инструменты, позволяющими решать конкретные проблемы.

Пробежимся очень кратенько по основным идеям в хронологическом порядке:

• Функциональное программирование

• ООП

• Структурный дизайн

• Шаблоны проектирования

• Рефакторинг

• YAGNI, KISS

• PoEAA: Transaction Script и Domain model,

• ORM

• DDD

• Hexagonal Architecture

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

50-е. Функциональное программирование

На заре компьютерной эпохи основными теоретиками в области вычислений были математики. И вот один из них, Джон Маккарти, придумал подход к написанию программ, где программа должна была представлять из себя композицию функций в математическом их смысле. То есть, вся парадигма вращается вокруг функций и их композиции. Простейшим примером такой функции будет всем известная парабола y(x) = x².

В целом, идея очень логичная, если посмотреть, какие задачи решали тогда компьютеры. Вот типичные из них:

• расчет баллистических таблиц для артиллерии,

• расчет необходимых параметров для создания ядерного оружия,

• расчет аэродинамической модели реактивного истребителя.

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

Спустя десятилетия начала осознаваться ценность одной интересной особенности функционального программирования - неизменности результата функции. Обратите внимание на параболу: эта функция всегда будет возвращать на один и тот же x один и тот же y. И вот это свойство отнюдь не гарантировано в иных подходах к программированию.

Похоже, впервые значимость этого свойства была отмечена в 1977 году Джоном Бэкусом в его лекции, посвящённой вручению ему Премии Тьюринга. Тогда он раскритиковал императивный стиль программирования фон Неймана за наличие у программ сайд-эффектов и состояния (стейта), а также его постоянного изменения, которое затрудняет работу с программой. С другой стороны Бэкус также замечает, что отсутствие состояния позволяет безопасно распараллеливать вычисления для их ускорения.

В целом, в современном хайпе вокруг функционального программирования лежат именно эти его преимущества:

• отсутствие сайд-эффектов и изменения состояния, снижающее количество багов;

• простота написания многопоточного кода из-за отсутствия гонок при изменении состояния.

А будут минусы?

Да, конечно! Строгие правила написания в рамках этой парадигмы приводят к разным казусам.

1. Если уж быть совсем строгим, то отсутствие стейта вынуждает нас использовать для циклов рекурсию. И любой джун знает, что в обычных ЯП без подготовки это приводит к переполнению стека. Следовательно приходится использовать либо стейт, либо специальные инструменты языка, если они есть. Откровенно говоря, это не прям уж беда, но очень важный нюанс, который показывает, что догматичность в ФП сразу приводит к необходимости городить костыли.

   

2. Куда сложнее история с тем, что функциональный код часто весьма непросто читать непривычным взглядом. И проблема тут далеко не в последнюю очередь в человеческом факторе, где новоиспеченные фанаты пытаются на полную катушку использовать все штучки-дрючки из мира ФП. Но последнее - это уже не столько проблема ФП, сколько вообще всего в нашей индустрии.

3. Сложность реализации тривиальных вещей может быть избыточна. Тут я про append-only решения типа ивент-сорсинга.

4. Распространённость ФП небольшая, а следовательно делать ставку в карьере исключительно на них нужно только из очень большой любви к искусству.

70-е. Структурный дизайн

В 70-е появилась концепция структурного дизайна, которая до сих пор являются фундаментом теории дизайна программного обеспечения. В оригинальной статье вводятся 2 главных термина: coupling и cohesion.

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

Cohesion - это про плотность этих coupling связей. Если после изменения в одном месте, надо что-то исправлять на другом конце программы, то это не очень хорошо. Гораздо лучше, если эти два места находятся рядом, в одном модуле.

Большое количество связей между разными частями программы - это спагетти код, плохой coupling. Высокий cohesion - это про модульность, хорошую скомпонованность и абстракцию кода, это хороший coupling.

В итоге структурный дизайн даёт нам 2 основных инструмента контроля качества нашего дизайна, которыми я рекомендую пользоваться каждый день: оценка связей разных точек программы и оценка плотности этих связей.

60е. ООП

Не буду особо расписывать про ООП, все и так все знают. Но главные 3 фишки в рамках рефлексии упомяну:

1. Данные и использующее их поведение в одном месте - это признак высокой плотности зависимостей, то есть cohesion. С плотно скомпонованным кодом гораздо проще работать, чем с развесистой лапшой.

2. Инкапсуляция крепко добавляет безопасности работы с объектом. Вы не сможете списать деньги со счета, если они там закончились. Невозможность перейти в невалидное состояние - это невозможность сохранить невалидное состояние.

3. Главная фишка ооп - полиморфизм. Этот механизм позволяет избежать дублирования в коде там, где иные подходы уже не справятся. А для самых запутанных случаев можно даже подключить шаблоны проектирования, которые как раз для ООП разработаны и были.

Вопреки распространенному нынче мнению, эти идеи, конечно же, актуальны до сих пор, поэтому мы к ним вернёмся, когда мы будем собирать в конце статьи Франкенштейна.

80е. Шаблоны проектирования

В 80е годы появилось сообщество фанатов ООП, Smalltalk community, из которого выросли потом очень важные для нашей индустрии люди и не менее важные идеи: паттерны, рефакторинг, Agile, TDD/BDD, DDD, CI, CD и ещё много чего интересного. Так вот с паттернов их творческий путь, по сути, и начался.

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

Идея собрать шаблоны для решения задач была заимствована Кентом Беком из сферы строительства. Первые паттерны были настолько специфичны, что ими, наверное, сейчас никто и не пользуется. Зато дальше появляется целое движение шаблонов, а паттерны льются, как из рога изобилия, как, например, всем известные GoF-паттерны. Но ещё чаще сейчас используются широко известные паттерны, которые были описаны в не столь известных книгах, как PoEAA, DDD, CD и т.п.: domain model, value, entity, repository, ORM, service layer, deployment pipeline и ещё много чего.

Конец 80х. Рефакторинг

До середины девяностых программное обеспечение обычно разрабатывалось большими дорогими и долгими проектами — водопадами.

Обычно это были 4 многомесячные фазы:

• сбор требований

• проектирование

• написание кода

• тестирование.

Главной проблемой такого подхода было то, что ошибки проектирования выяснялись только на этапе написания кода или, что ещё хуже, на этапе тестирования. Доработки очень часто требовали больших и масштабных изменений в кодовой базе. А это, как мы знаем, чревато тем, что можно сломать вообще все, что работало до этого.

И вот в 90-м году William Opdyke и Ralph Johnson (тот самый из GoF) публикуют статью по дисциплине изменения кодовой базы посредством последовательности очень небольших шагов. Эту дисциплину они впервые назвали рефакторингом. В 95-м эта дисциплина стала основным способом проектирования системы на первом Extreme Programming проекте — Chrysler comprehensive compensation system. Впервые дизайн системы проектировался не заранее, а эволюционировал с ходом разработки.

В 1999 по следам этого проекта Мартин Фаулер напишет книгу про Рефакторинг. В этой книге описан сам подход изменения кода очень небольшими шагами, где программа остаётся рабочей на всем протяжении изменения. Лакмусовая бумажка: если вы можете остановиться в любой момент на середине рефакторинга и закончить через месяц, когда появится возможность, значит вы все делаете правильно.

В книге впервые вводится понятие Code Smell, которое указывает на наличие лишних coupling‑связей или проблем с читабельностью кода, а также приводится перечень этих код‑смеллов.

Описаны также основные методы рефакторинга — способы устранения этих лишних coupling‑связей и повышения того самого cohesion и читабельности. Скорее всего, в вашей среде разработки эти методы даже встроены: это те самые extract method, inline variable и прочее, что было добавлено во все IDE после публикации этой книжки. Впрочем, этим всем ещё надо уметь пользоваться, но это уже совсем другой разговор. Для этого вам надо сюда.

90е. YAGNI

В 90-е стартанул первый Extreme Programming проект, который я уже упомянул. Главная идея, которая стояла за экстремальным программированием — взять все хорошее и довести до максимума, до экстремума:

• вместо трехмесячной дизайн фазы постоянный рефакторинг;

• вместо многомесячной фазы тестирования — прогон автотестов несколько раз в день;

• вместо одного релиза раз в год — поставки раз в 2 недели;

• вместо периодического код‑ревью — парное программирование;

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

Туда же добавилась и ещё одна практика: самое простое, что может работать. Эта практика была призвана бороться с главной причиной роста стоимости разработки во времени: со сложностью кодовой базы и программного обеспечения.

Минимализм проявлялся в постоянной чистке кода посредством рефакторинга от всего, что не было необходимо для прохождения тестов. Применялось правило YAGNI — you aren't gonna need it.

У Кента Бека было 4 требования к коду:

• проходит тесты

• раскрывает намерение

• нет дублирования

• наименьшее число классов и функций.

Нулевые. PoEAA

В начале нулевых Мартин Фаулер выпускает книгу Patterns of Enterprise Application Architecture, которая, на самом деле, во многом очень быстро устареет. Но там появляется очень важная мысль, которая актуальна до сих пор. При разработке приложения вам придётся выбрать между двумя подходами: Transaction script и Domain model.

Transaction script — это простейшая программа, которая на разные вызовы просто выполняет соответствующие последовательности шагов, сохраняет данные и возвращает результаты. Условно: приняли данные, загрузили из базы текущее значение, сделали проверку и сохранили изменённое значение

Domain model — это подход, в котором вы уже моделируете свою предметную область в коде. Вы работаете не просто с данными и вводом‑выводом. Теперь вы делаете модель предметной области, которая сама должна контролировать свою консистентность и, где нужно, абстрагировать свои детали посредством интерфейсов.

Для примера, вы загружаете из хранилища модель инвестиционного портфеля клиента и пытаетесь совершить с ней какое‑то действие: например, продать набор инструментов из портфеля. В итоге сама модель уже определяет, возможно ли это сейчас, и по какой цене нужно предложить выставить бумаги на продажу. У каждого инструмента (акции, облигации, опционы) свои нюансы (купоны, дивиденды и т. п.), но у них у всех есть общие черты: их можно продать и купить, у них есть цена, эмитент и владелец.

В этой дихотомии Transaction Script проще, и его стоит выбрать, если система простая и сложнее становиться ТОЧНО не будет. Ее написали за пару недель и больше не трогают и трогать не будут.

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

ORM

В томже PoEAA появляется описание нового паттерна: object mapper, он же object‑relation pattern (ORM). Взрыв популярности ООП в девяностые показал сложность раскладывания объектов по таблицам: реляционные представления и объектные представления данных друг на друга ложились не очень хорошо и требовали специальных абстрактных мапперов для перекладки. Довольно скоро такие ORM появились уже в открытом доступе и быстро получили свою популярность.

Но лет через 10 за ними придёт и ORM hate — движение по отказу от ORM из‑за проблем со сложностью и непредсказуемостью таких фреймворков под нагрузкой.

И тут я хочу предостеречь читателя от упрощённого понимания проблемы: ORM‑фреймворки действительно сложны, но только потому, что объектно‑реляционный маппинг — сложная проблема. Любой, кто пытался написать на простых запросах маппинг один ко многим прекрасно понимает, что в ряде случаев отказ от ORM приведёт лишь к написанию собственного кастрированного ORM.

Поэтому вместо необоснованного повсеместного отказа от ORM я бы предложил скорее решать проблемы точечно: настраивать ORM под свою задачу и использовать обычные запросы там, где эффективности ORM вам не достаточно.

Впрочем, в нагруженных системах даже эти решения требуют очень надёжного нагрузочного тестирования. Поэтому, в первую очередь, я бы рекомендовал, где это возможно, рассмотреть альтернативы реляционным базам данных, чтобы не решать проблему объективно‑реляционного маппинга вообще. На крайне нагруженных системах, очевидно, нереляционные базы данных уже по умолчанию являются фаворитами за счёт неограниченного горизонтального масштабирования.

Нулевые. DDD

Упоминая шаблон Domain Model, нельзя обойти вниманием книжку Domain Driven Design 2003 года за авторством Эрика Эванса. Именно в ней впервые вводятся шаблоны entity, value, aggregate и repository.

В целом, пересказывать книгу смысла особого нет — это большое пособие по построению доменных моделей в коде и работе с ними. Если хочется ознакомиться с основными идеями, то я рекомендую вот это видео. Если хочется подробный обзор из первоисточника, то тут уже лучше читать оригинальную книжку.

Нулевые. Hexagonal Architecture

В 2003 Алистар Кокберн выпустил статью по гексагональной архитектуре, которая, на мой взгляд, венчает эволюцию развития инженерной мысли в области архитектуры приложения./

Идея заключалась в том, чтобы выделить куски кода, взаимодействующие с конкретными технологиями в отдельные адаптеры:

• контроллеры и клиенты для REST,

• репозитории для баз данных,

• консьюмеры и продюсеры для брокеров сообщений и т. п.

Таким образом, оставшийся код представляет из себя абстрактное «приложение» (Application‑layer в оригинальной терминологии), которое работает независимо от выбора технологии и реализации адаптера.

Приложение в такой парадигме само собой раскладывается в трехуровневую структуру: на первом уровне — входные адаптеры (контроллеры, консьюмеры, CLI, шедулеры и т. п.), на втором уровне — ядро или «приложение», на третьем — исходящие адаптеры (репозитории, клиенты, продюсеры).

Автор идеи декларировал ценность такого подхода, в первую очередь, в написании «быстрых» тестов на бизнес‑логику ядра в «приложении»: можно обойти медленные адаптеры первого уровня и заменить быстрыми фейками адаптеры третьего уровня. Такие тесты будут быстрее интеграционных даже с in‑memory базой данных в десятки раз, позволяя прогонять весь сьют в сотни тестов за пару секунд, что буквально незаменимо для рефакторинга. Того самого рефакторинга, который последовательность маленьких атомарных изменений структуры без смены поведения, а не того, что сейчас под этим словом часто понимают.

С этим утверждением автора я лично согласен, но ничуть не менее полезными нахожу и другие преимущества абстрагирования адаптеров. В нашем опыте есть несколько хороших примеров, где это абстрагирование очень сильно нас спасало от больших переделок.

Небольшой пример из опыта нашей команды

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

В итоге, мы пришли к новой схеме: соседняя команда стримила нам в брокер эти сущности в прямом эфире, мы их прихранивали у себя и, при необходимости, брали уже из своей базы со всеми необходимыми для нашей задачи оптимизациями. Но самое вкусное тут то, что нам удалось это провернуть, просто подменив адаптер REST‑клиента на адаптер репозитория, не тронув ни одной строчки с бизнес‑логикой.

На самом деле, такой пример, отнюдь не уникален. После успеха этого решения по нашим стопам пошла и команда, делающая UI: заколебав другую команду своими запросами на предоставление апишек и их оптимизацию, они тоже перешли, в итоге, на event‑driven подход на основе стриминга со своим хранилищем.

Также такое абстрагирование оказывается полезным при смене версий апи, при переходе с синхронного на асинхронное взаимодействие, при изменении структуры БД, оптимизации запросов и т. п.

Собираем воедино

Теперь постараемся собрать все эти идеи воедино, чтобы дать рекомендации по построению структуры приложения.

Повторюсь, мне не известны какие‑либо источники, надежно подтверждающие хоть какое‑то влияние структуры приложений хоть на что‑то кроме комфорта разработчика, так что то, что я сейчас буду рассказывать — это однозначная отсебятина и вкусовщина. Мы в своей команде делаем так (и тоже с вариациями). Если кому‑то еще пригодится — буду только рад.

Сгруппируем эти идеи и рассмотрим вопрос архитектуры приложения с 3 сторон:

• идеология — ФП, ООП, шаблоны;

• процессы — Рефакторинг, YAGNI, Структурный дизайн;

• структура — DDD, Hexagonal Architecture.

Идеология

Первое, что может очень сильно повлиять на архитектуру приложения — это идеология. Особенно, если эта идеология навязана языком или фреймворком. Тут очень простая рекомендация: если вы еще не успели влюбиться в какую‑то одну концепцию или идею до беспамятства, то и не стоит. Используйте преимущества множества идеологий.

Из функционального программирования я бы порекомендовал взять уважение к неизменяемым структурам данных и избегание сайд‑эффектов, где это возможно (например, CQS).

Вынужден предостеречь, это может вас подтолкнуть к append‑only и event‑sourcing подходам, которые хоть часто и бывают полезны, но далеко не везде себя оправдывают, а потому могут сильно усложнить без особой надобности вашу архитектуру.

У ООП свои очень серьезные преимущества, которые я рекомендую не игнорировать. Повторюсь, эти преимущества:

• высокий cohesion за счет хранения данных и поведения в одном месте

• хорошие инструменты инкапсуляции модели, защищающие вашу модель от некорректного состояния

• полиморфизм, позволяющие устранять дублирование там, где в ином случае вы были бы обречены.

Ну и я давно подозреваю, что половина GoF Design Patterns в языках без полиморфизма вряд ли возможна. А с ООП у вас есть целая книжка с полезными костылями под каждую конкретную проблему.

Процессы

Не всегда путь влияет на конечный результат, но разработка ПО — это именно тот случай. Ваши процессы однозначно оставляют отпечаток на вашей архитектуре. Поэтому пара советов на тему процессов.

Я очень сильно рекомендую строить вашу архитектуру в эволюционной парадигме:

• избегать продолжительного проектирования до разработки и преждевременных оптимизаций

• стараться вывести структуру приложения и его основные компоненты в процессе разработки, наблюдая за кодом и связями в нем

• удалять все, что оказывается лишним

• постоянно рефакторить с целью повышения читабельности кода.

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

Такой подход позволяет избавиться от некорректных абстракций и лишних структур, потому что при рефакторинге мы основываемся уже на реально получившихся зависимостях и реализации. Если мы подготовим структуру до разработки на основе каких‑то догадок и спекуляций, то в процессе реализации мы, скорее всего, станем заложниками собственных ошибок и неправильных оценок. Пример такого рефакторинга можно подсмотреть вот в этом моем старом видео.

Это итеративный процесс: сначала немного поведения, поэтом небольшой рефакторинг с приведением структуры к приемлемому виду, основываясь на код‑смеллах, каких‑то идеях из DDD и собственных представлениях о добре и зле. В нашей команде этот процесс является частью цикла Red‑Green‑Refactor.

Структура

Мы в своей команде основываем нашу архитектуру на DDD и Гексагональной архитектуре. Для этого выделяем 3 основных слоя: адаптеры, приложение и домен.

Домен

Это часть кода, которая не зависит ни от каких фреймфорков и внешних библиотек. Классы и функции названы по терминам из предметной области и богаты бизнес‑логикой. Понять, относится ли код к этому слою очень легко: надо задать себе вопрос, была бы актуальна эта логика, если б компьютеров не было? Например, маршрут, расход топлива и количество пассажиров — явные кандидаты в этот слой. Если ваша предметная область связана с компьютерами, это правило, конечно, не сработает, но идея, думаю, ясна.

Код попадает в доменный слой из слоя приложения. Происходит это через рефакторинг: выделяются куски кода, которые удаётся вынести, и переносятся в доменные сущности. Самый лучший ориентир, куда надо что‑то положить — код‑смелл Feature Envy: если в параметрах функции есть доменный объект, то это хороший повод сделать её методом этого объекта.

Что не рекомендую:

• Анемичная доменная модель
  
  Когда вся логика лежит в сервисах, а не в доменных объектах, то это все еще работает, но уже не особо что‑то моделирует. Таким образом вы лишили себя всех преимущств ООП: высокого cohesion, инкапсуляции модели, полиморфизма для разруливания дублирования и абстракции логики. Помимо этого вы перемешали логику уровня приложения с логикой предметной области, и теперь каждый раз надо отделять виски от колы, чтобы что‑то понять.
  
  В целом, анемичная доменная модель — это Transaction Script с издержками доменной модели, худшее из двух подходов.

• Нарушение изоляции модели
  
  Очень часто приходится видеть модели, в которые протекла логика других уровней: это и код ORM, и запросы какие‑то, и ActiveRecord паттерн, иногда даже какие‑то DTO или иные детали внешних контрактов. Этот код явно не относится к предметной области, а, следовательно, скорее лишний.
  
  Чем это чревато? Связанностью вашей модели с логикой других слоёв: вы не сможете, когда вам потребуется, быстро отрефакторить модель из‑за того, что у вас будет ломаться поход в БД. Вы не сможете оптимизировать доступ к БД без большого рефакторинга через всю кодовую базу. При смене контракта вы будете случайно ломать бизнес‑логику и потом мучительно её отлаживать.
  
  Поэтому я рекомендую максимально изолировать модельный код от всего мирского: никаких зависимостей ни на какие фреймворки, ничего не связанного с предметной областью.

Адаптеры

Это часть кода для работы с технологиями: базами, рестами, очередями и прочим. Их задача — полностью абстрагировать доступ к технологии так, чтобы на других уровнях не было никаких деталей. Снаружи адаптера не должно быть понятно, ходит ли он в реляционную базу или просто по ресту запрашивает результаты у другого сервиса: максимальная асбтракция. При этом также в самом адаптере должна быть только логика доступа к технологии, все остальное — за его пределами.

Как понять, что код принадлежит этому слою? Он будет актуален только в контексте этой технологии. Если какая‑то часть логики адаптера актуальна для любой технологии, то это повод задуматься о корректности выбора слоя.

Обычно на выходе и на входе из адаптеров мы используем доменные объекты, которые маппятся на объекты адаптеров: ORM‑сущности или DTO.

Каждый адаптер — это свой небольшой мир, маленький модуль, библиотечка, которая никак не соприкасается с другими адаптерами. И это, обычно, созвездие классов. Например:

• для контроллера — это сам контроллер, дтошки, код отлова исключений;

• для Hibernate‑хранилища — класс хранилища, репозиторий, сущности.

Приложение

Между адаптерами и доменом в самом центре находится слой приложения. Это тонкий сервисный, предназначенный для оркестрации работы модели и адаптеров. В идеале в слое приложения не должно быть почти никакой логики. Хороший пример: взяли доменный объект в адаптере, сделали манипуляцию, положили в адаптер. При этом всю сложность надо пытаться упрятать в домен. Понятное дело, в реальности бывает по‑разному, но эта мысль должна быть ориентиром.

Как понять, что код принадлежит этому слою? Он будет актуален только в контексте вашего приложения и вашей компании. Например, вы пишите Яндекс‑Такси, и тут вас окружает один набор команд и микросервисов, тогда как в СитиДрайве это будет совсем другой набор команд и микросервисов. Вот детали архитектуры, окружающей ваше приложение и порядок взаимодействия с ней — это и есть логика этого уровня.

Техника безопасности

1. Отсебятина. Мне не известны надежные свидетельства того, что описанные в первой части идеи достоверно делают разработку проще, дешевле или приятнее. Поэтому вы в праве выбрать оттуда все, что вам нравится, или вовсе отказаться от всего.

2. Частный случай. Я описал именно подход нашей команды: мы его собрали из кусочков разных идей и адаптировали под наши домены, наши процессы разработки, тестирования и рефакторинга. И тестирование тут — самое главное. Мне не известны надежные свидетельства и того, что наш подход достоверно делает разработку проще, дешевле или приятнее. Нам кажется, что оно так, но, когда кажется, креститься надо. Если вам этот подход кажется избыточно сложным — это нормально, можете, выбросить оттуда все, что вам не нужно.

3. Я не упомянул Х. Если вы не увидели в описании свой любимый подход: реактивное программирование или, не знаю, Event‑sourcing, то это не значит, что эти идеи плохие. Просто я не могу описать в рамках одной статьи вообще все, поэтому я расписал только то, что посчитал самым важным.

---

Меня зовут Саша Раковский. Работаю техлидом в расчетном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку очень дорого. Законченный фанат экстремального программирования, а значит и DDD, TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет, для этого я здесь — делюсь опытом. Если стало интересно, добро пожаловать в мой блог.