Подходы к декомпозиции бэкендов информационных систем

Критерии

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

Качество декомпозиции я буду оценивать по следующим критериям:

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

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

Что касается лёгкости применения, то её я буду оценивать по таким критериям:

Пакетирование по слоям и техническим аспектам

Картинки кликабельны

Пример

Этот подход настолько прост и существует настолько давно, что, кажется, это уже коллективное бессознательное нашей индустрии. Судя по всему, своими корнями он уходит в статью Дейкстры The structure of the “THE”-multiprogramming system, датированную 67 годом, что делает его одним из самых ранних подходов.

Несмотря на свой возраст, этот подход является самым распространённым и по сей день и, думаю, он знаком всем разработчикам без исключения. Способ группировки заключается в том, что команда выбирает несколько аспектов реализации (самые частые примеры - контроллеры, сервисы, репозитории/дао, сущности, дто, фабрики, исключения, перечисления) и группирует классы по ним. Классы, которые не удаётся однозначно отнести к одному из этих аспектов, сваливают в специальную группу, которую обычно называют utils или common.

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

Такая декомпозиция теоретически должна скрывать способ реализации технических аспектов, например, способ работы с БД. Однако на практике, детали реализации слоёв очень часто "протекают" через границы, результатом чего становится отсутствие какого бы то ни было сокрытия информации вообще.

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

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

В итоге декомпозиция по слоям представляет собой сочетание врождённой высокой сцепленности между пакетами и белого пятна в проектировании внутри пакетов. Эта гремучая смесь приводит к превращению системы в печально известный Big Ball of Mud (большой ком грязи) уже к концу первого года своей жизни.

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

Большинство нетривиальных изменений таких систем будет затрагивать множество пакетов. А удаление единственного пакета (контроллеров), которое не сломает сборку, сразу же сделает всю систему бесполезной для пользователя.

С точки зрения масштабируемости слоёная декомпозиция также даёт не лучший результат. Постоянно развиваемая система довольно быстро доходит до 20-30 классов одного типа (то есть в одном пакете) и снова возникает проблема их группировки.

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

Однако на практике слоёную декомпозицию не выбирают. Чаще всего это единственный известный и понятный разработчикам способ декомпозиции. И разработчиков сложно в этом винить, декомпозиции систем действительно нигде не учат - меня самого не учили в университете, и соответствующих курсов я ни разу не видел. С этим мнением согласен и Джон Оустерхаут, автор A Philosophy of Software Design:

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

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

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

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

Итоговая оценка пакетирования по слоям (по пятибалльной шкале):

Пакетирование по фичам

Пример.

Найти оригинальный источник идеи пакетирования по фичам у меня не получилось, но этой теме посвящено множество постов:

Хотя ни один из них я не могу назвать ни авторитетным, ни исчерпывающим.

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

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

Декомпозиция по фичам только звучит просто (и то не для всех). Когда же вы сядете и попытаетесь декомпозировать систему по фичам, у вас тут же возникнет множество вопросов: "А фича - это вообще что такое?", "Как мне из требований получить набор фич?", "Судя по примерам, фича - это таблица. Мне что, заводить по пакету на каждую таблицу?", "А что делать с таблицами связками?", "Что делать с функциями, которые затрагивают две и более таблицы - в какой пакет их помещать?", "А что делать с функциями, которые работают не с таблицами, а с REST API?", "А с S3?", "А куда мне положить DSL создания Excel файлов для нескольких фич? В utils?". Ответы на все эти вопросы придётся искать самостоятельно, потому как все посты ограничиваются поверхностным описанием идеи.

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

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

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

Итоговая оценка пакетирования фичам:

Пакетирование по компонентам

Примеры: [1], [2].

Автором пакетирования по компонентам является Саймон Браун, описавший его в посте Mapping software architecture to code (также см. 1, 2, 3, и главу 34 "Missing Chapter" из Clean Architecture).

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

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

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

Уже в процессе редактуры этого поста я наткнулся на твит Брауна:

Основываясь на этом твите, можно предположить, что подход к декомпозиции Брауна по сути совпадает с пакетированием по объектам. Но это не точно.

И хотя с описанием пакетирования по компонентам дела обстоят лучше, чем с описанием пакетирования по фичам, чёткой методики выявления компонентов Браун также не предлагает. Поэтому итоговая оценка примерно такая же.

Итоговая оценка пакетирования компонентам:

Ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD)

Примеры: [1], [2], [3].

DDD - это полноценный подход к проектированию, описанный в одноимённой книге Эрика Эванса. Помимо этой книги, есть ещё ряд очень хороших книг - Domain Modeling Made Functional, PPP of DDD, Implementing Domain-Driven Design, суммарно на 2200 страниц. А ещё множество менее популярных книг и бессчётное количество постов в интернете.

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

Мне самому DDD импонирует и в Эргономичном подходе я позаимствовал из DDD все базовые блоки тактических паттернов. В частности, агрегаты играют одну из ключевых ролей в объектно-ориентированной декомпозиции. Однако вместо того, чтобы работать по DDD, я начал делать Эргономичный подход. Этому есть две основные причины - тяжеловесность и расплывчатость DDD.

Тяжеловесность DDD проявляется как в обучении, так и в применении.

DDD - это очень большая штука, на изучение которой требуется очень много времени. Как минимум надо будет прочитать 1000 страниц оригинальной книги и PPP of DDD или Implementing DDD. Мне для уверенного понимания стратегических паттернов не хватило даже прочтения всех 4 указанных выше книг по два раза (по разу от корки до корки, и ещё по разу разбираясь с отдельными концепциями).

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

Касательно декомпозиции DDD предусматривает два уровня - ограниченные контексты и агрегаты. Что это такое? А вот поди разбери.

Само определение ограниченного контекста является наглядной демонстрацией сложности и расплывчатости подхода.

Как декомпозировать задачу на ограниченные контексты тоже в двух словах не объяснить (мне, по крайней мере).

Как вариант - границы контекста определяются языковыми границами. Осталось выяснить самую малость - где проходят языковые границы.

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

Полноценного руководства по декомпозиции ограниченных контекстов на модули DDD также не предлагает. В оригинальной книге этому посвящён целый раздел, но я бы описал его как "вода-вода, не используйте слои, вода-вода". Если не слои, то что? Ответа нет. В первой книге.

Зато есть в Implementing DDD.

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

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

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

Итоговая оценка пакетирования по ограниченным контекстам и агрегатам:

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

Существует ли серебряная пуля, которая позволит нам быстро и без больших усилий выполнять качественную декомпозицию систем? Я утверждаю, что да и что она всегда была у нас под носом. И имя ей - объектно-ориентированная декомпозиция

Пакетирование по объектам, ака объектно-ориентированная декомпозиция

На рубеже 20 и 21 веков многие книги по ООП/Д/А (например, Object-Oriented Software Engineering, Designing object-oriented software, Applying UML and Patterns) в дополнение к методике проектирования классов, предлагали и рекомендации по их последующей группировке в более крупные структуры. Однако я ни разу не видел, чтобы кто-то применял эти методики в реальной жизни. Полагаю, потому что все эти методики очень тяжеловесные.

Поэтому я разработал "легковесную" методику выполнения объектно-ориентированной декомпозиции.

Как очевидно из названия, этот подход предполагает раскладку по пакетам разных объектов. В данном контексте под объектом я понимаю не экземпляр класса, а более крупную структуру, которая может быть реализована группой классов (группой экземпляров классов, если быть точнее). Эту структуру я называю объектом, потому что она обладает всеми присущими ему характеристиками - состоянием, которое она абстрагирует и инкапсулирует за высокоуровневым поведением. Идентичность тоже можно перенести на уровень пакетов, но на практике это требуется редко, поэтому я не стану на ней останавливаться.

Идея объектов-пакетов принадлежит не мне - я её подглядел в Object-Oriented Software Engineering Ивара Якобсона (одного из соавторов UML). В этой книге Якобсон оперирует тремя видами объектов - объекты анализа, объекты дизайна и объекты (модули) языка программирования.

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

Общая концепция ОО-подхода очень проста. Есть операции - атомарные единицы поведения, которые могут быть вызваны извне (пользователем через UI или внешней системой через [REST] API). Есть ресурсы, которые обеспечивают операции (в первую очередь коллекции в хранилищах данных, но это могут быть и файлы, и внешние системы, и внешние устройства). Операции и обеспечивающие их ресурсы надо так поделить на объекты дизайна, чтобы каждый ресурс обеспечивал операции только одного объекта. Наконец, ресурсы надо инкапсулировать в объектах дизайна - исключить возможность обращения к ресурсу напрямую снаружи объекта.

Интерфейс объекта дизайна может быть дополнен операциями, необходимым другим объектам. Но в общем случае для взаимодействия объектов лучше использовать асинхронный обмен сообщениями и событиями через посредника (очередь).

Кратко методика проектирования объектов дизайна (ака декомпозиции на пакеты) состоит из трёх основных шагов:

Первый шаг этой методики - определение операций и ресурсов - я описал в "посте с описанием построения диаграммы Эффектов проекта True Story Project".

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

Эта методика относительно простая и механистическая, но даёт на удивление хорошие результаты.

Очевидно, что полученная декомпозиция обладает высокой степенью сокрытия информации - детали реализации (ресурсы) операций системы скрываются внутри объектов дизайна. Такая степень сокрытия информации является прочным фундаментом и для сведения сцепленности к минимуму.

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

Наконец, масштабирование также учтено и встроено в саму методику.

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

То же касается и применения - проектирование объектов находится посередине между предельно простым проектированием слоёв и очень сложным проектированием фич, компонентов и ограниченных контекстов.

Итоговая оценка пакетирования по объектам:

Заключение

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

Для того чтобы решить эти проблемы, я разработал методику объектно-ориентированной декомпозиции системы на пакеты. Она проще в изучении и применении группировок по фичам, компонентам и ограниченным контекстам/агрегатам, но даёт результаты такого же качества.

В следующем посте я вернусь к серии о диаграмме эффектов и подробно рассмотрю процесс выполнения объектно-ориентированной декомпозиции на конкретном примере.

Приложение А. Сводные данные

Картинка кликабельна