Архітектура Angular для великих застосунків: межі, що витримують зростання

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

Почніть із ділової карти: можливостей, учасників, критично важливих процесів, джерел достовірних даних, відповідальності команд, обмежень випуску та наслідків відмови. Потім визначте межі маршрутів, відкритих API, стану, інфраструктури й розгортання. Angular надає самостійні компоненти, маршрутизацію, впровадження залежностей, сигнали та засоби складання; ці механізми втілюють обрану модель, а не замінюють її.

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

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

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

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

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

Зробіть напрямок залежностей обов’язковим правилом

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

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

Дозволяйте обмежені в часі винятки, коли це виправдано доказами потреби у випуску. Кожний виняток повинен мати відповідального, причину, охоплений зв’язок, ризик, дату завершення та завдання на усунення. Перевіряйте, чи запропонований спільний тип справді має однаковий зміст в обох предметних областях: однакові поля ще не доводять однакової семантики. Якщо значення можуть розійтися, перетворюйте дані на межі.

Узгодьте відкладене завантаження маршрутів із межами продукту

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

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

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

Зберігайте спільний код малим і сталим за змістом

Спільний код має бути простим, сталим і позбавленим прихованих ділових повноважень. Добрі кандидати — доступні основні елементи оформлення, форматування з явно заданою мовою й регіоном, загальні механізми перевірки, порти телеметрії та засоби передавання даних. Допоміжна функція, названа за діловим поняттям, належить відповідній предметній області, навіть якщо зараз її викликають два екрани.

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

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

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

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

Для локального синхронного стану використовуйте сигнали компонентів, а для похідних значень — обчислювані сигнали. Обмежуйте служби або сховища робочого процесу маршрутом, якщо їхній строк життя збігається зі строком життя маршруту. Уводьте загальне сховище стану застосунку лише для даних, які справді мають загальних для всього застосунку читачів, авторів змін і строк життя. Єдине глобальне сховище перетворює непов’язані рішення про випуск на одну міграцію схеми.

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

Сховайте подробиці браузера й інфраструктури за портами

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

Свідомо обирайте область дії постачальника залежності. Постачальники рівня застосунку підходять справжнім одиничним екземплярам; постачальники маршруту — налаштуванням ділової можливості та стану на час життя маршруту; постачальники компонента — ізольованим екземплярам, що мають зникати разом із компонентом. Ієрархічні механізми впровадження залежностей Angular дають потужне керування областю, але випадково обраний рівень може продублювати сеанси, надто довго утримувати стан або приховати, яка реалізація активна.

Узгоджуйте помилки й телеметрію на межі адаптера, не стираючи корисних подробиць. Додавайте ідентифікатор зв’язку, операцію та контекст предметної області; вилучайте чутливі значення; відрізняйте недоступність, відсутність дозволу, неправильні дані, конфлікт і невідому помилку. Де це доречно, перевіряйте формування сторінок на сервері або виконання поза браузером. Безпосереднє звернення до window, сховища чи SDK постачальника всередині функціональних областей робить такі середовища й перевірки крихкими.

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

Закріпіть відповідальну команду за кожною предметною областю та частиною платформи. Відповідальність охоплює вплив на план розвитку, перегляди, справність у робочому середовищі, вразливості, оновлення залежностей, перенесення, документацію та підтримку, а не лише право об’єднувати зміни. Опублікуйте відкритий API й очікування від служби, щоб споживачі знали, як просити про зміну та як швидко опрацьовуватимуть інциденти.

Узгодьте будову сховища коду зі способом співпраці. Єдине сховище може показати граф залежностей і надати спільні засоби, але не створює самостійності, якщо кожна зміна потребує центральної команди. Визначте власників коду, перевірки змінених проєктів, розподілених відповідальних за супровід, явні правила випуску та шляхи передавання проблем на вищий рівень. Зосередьте управління платформою на сумісності й результатах, а не на контролі стилю заради самого контролю.

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

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

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

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

Переглядайте правила щокварталу та після значних змін продукту чи команд. Прибирайте перевірки, які більше не захищають результат, посилюйте правила після підтвердженого інциденту й усувайте порушення обмеженими частинами. Облікуйте винятки та зміну показників архітектурної придатності. Мета полягає не в довічно бездоганній схемі, а в системі, чиї обмеження залишаються видимими, корисними й доступними для зміни.

• Групуйте маршрути, інтерфейс, координацію дій, стан, доступ до даних і типи предметної області за діловою можливістю з відповідальною командою та вузьким відкритим API.
• Визначте дозволені відносини між предметними областями й шарами, а потім перевіряйте імпорти, відкриті точки входу, цикли та винятки під час безперервної інтеграції.
• Розміщуйте маршрути з відкладеним завантаженням навколо можливостей із незалежною навігацією та перевіряйте пакети, переходи, дані, відмови й відновлення на справжніх пристроях.
• Спільно використовуйте сталі основні елементи, складові системи оформлення та порти платформи; мінливий діловий зміст залишайте в предметній області, яка за нього відповідає.
• Тримайте стан у найвужчій області, що відповідає його джерелу, читачам, авторам змін, строку життя, скиданню, збереженню та потребам відновлення.
• Надавайте типізовані порти для застосунку, а механіку браузера, постачальника, передавання даних, телеметрії та сховища залишайте в замінних адаптерах.