Архитектура Angular для крупных приложений: границы, выдерживающие рост

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

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

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

Организуйте приложение по деловым возможностям

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

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

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

Закрепите допустимое направление зависимостей

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

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

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

Согласуйте отложенную загрузку маршрутов с границами продукта

Применяйте отложенную загрузку на границах частей продукта с независимой навигацией. Маршруты Angular могут загружать автономный компонент через loadComponent или набор дочерних маршрутов через loadChildren. Граница маршрута также может ограничивать область поставщиков зависимостей и состояния. Так решение о загрузке согласуется с навигацией, ответственностью, предоставлением доступа и очисткой ресурсов, а не со случайным количеством файлов.

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

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

Сохраняйте общий код небольшим и устойчивым по смыслу

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

Разделяйте общие области по назначению и ответственности, а не создавайте единый магнит для зависимостей. Пакет системы оформления может содержать компоненты и переменные; пакет платформы — порты, которыми пользуется приложение; небольшие вспомогательные пакеты — чистые функции. Для каждого определите открытый API, правила изменений, ответственного за сопровождение и проверки со стороны потребителей. Избегайте модулей-сборщиков со сплошным повторным экспортом, которые случайно открывают внутренние составляющие.

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

Размещайте состояние в самой узкой полезной области жизни

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

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

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

Скройте подробности браузера и инфраструктуры за портами

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

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

Согласуйте ошибки и телеметрию на границе адаптера, не стирая полезных подробностей. Добавляйте идентификатор связи, операцию и контекст предметной области; удаляйте чувствительные значения; отличайте недоступность, отсутствие разрешения, неверные данные, конфликт и неизвестную ошибку. Где это уместно, проверяйте формирование страниц на сервере или выполнение вне браузера. Прямое обращение к window, хранилищу или SDK поставщика внутри функциональных областей делает такие среды и проверки хрупкими.

Развивайте ответственность команд вместе с архитектурой

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

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

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

Закрепите архитектурные схемы автоматическими проверками

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

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

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

• Группируйте маршруты, интерфейс, координацию действий, состояние, доступ к данным и типы предметной области по деловой возможности с ответственной командой и узким открытым API.
• Определите разрешенные отношения между предметными областями и слоями, а затем проверяйте импорты, открытые точки входа, циклы и исключения во время непрерывной интеграции.
• Размещайте маршруты с отложенной загрузкой вокруг возможностей с независимой навигацией и проверяйте пакеты, переходы, данные, отказы и восстановление на настоящих устройствах.
• Совместно используйте устойчивые основные элементы, составляющие системы оформления и порты платформы; изменчивый деловой смысл оставляйте в предметной области, которая за него отвечает.
• Держите состояние в самой узкой области, соответствующей его источнику, читателям, авторам изменений, сроку жизни, сбросу, сохранению и потребностям восстановления.
• Предоставляйте типизированные порты для приложения, а механику браузера, поставщика, передачи данных, телеметрии и хранилища оставляйте в заменяемых адаптерах.