При создании интерфейсных приложений мы можем в конечном итоге перестроить наш монолит с использованием новой, более изящной технологии. Однако никакие модные словечки не спасут нас от последствий строительства монолита.
Нажмите здесь, чтобы опубликовать эту статью в LinkedIn »
Прежде чем мы углубимся в эту статью, я хочу напомнить, насколько важно думать о том, в каком контексте / организации и какой части вашего проекта формируется монолит. В некоторых случаях монолит может быть менее плохой идеей, чем альтернатива.
Организация кода
Итак, вы решили, что хотите создать интерфейсное приложение для своей архитектуры внешнего интерфейса. У вас есть одна команда разработчиков, которая работает над интерфейсом. Как должна выглядеть структура папок проекта?
Организовать файлы по типам файлов довольно просто. В реакции с redux это означает, что у вас будут как минимум папки: действия, редукторы, контейнеры, компоненты. В Angular вы, вероятно, знакомы с другой структурой: компонентной архитектурой, описанной Джоном Папой. Каждый компонент соответствует принципам SOLID.
Организация файлов на основе типов хороша в том смысле, что она устраняет много накладных расходов с точки зрения именования компонентов и организации того, какие файлы какому компоненту принадлежат. Если вы хотите сделать MVP или работать в одной команде разработчиков, это может быть хорошим вариантом.
Работа в масштабируемой среде
Когда вы начинаете работать в более масштабируемой среде с несколькими командами, которые должны работать независимо, над одним и тем же клиентским приложением, это становится более сложной задачей. Вы можете начать разбивать свой проект на разные пакеты, псевдонимы большие компоненты. Важно, чтобы каждый из этих пакетов и его компоненты работали только в ограниченном контексте, который мы знаем из Домен-ориентированного проектирования. Это потому, что это помогает сделать команды менее сплоченными и более автономными, но добавляет некоторые накладные расходы в виде времени при планировании проекта. Однако такое планирование может быть солидным вложением в стабильную скорость разработки и ремонтопригодность на протяжении всего жизненного цикла программного обеспечения.
Невыполнение планирования может привести к гниению кода, снижению скорости разработки и, в конечном итоге, к отказу от всего проекта.
Собираем все вместе
Каждый из пакетов можно рассматривать как микросервис, который можно выпускать отдельно по-разному. Основной проект может с помощью таких инструментов, как Webpack использовать все опубликованные пакеты. Интересный подход реализован в проекте single-spa, который также не зависит от фреймворка. В зависимости от того, что вы делаете, вы можете получить распределенный монолит. Однако различные способы и их соответствующие подводные камни достойны отдельной статьи.
