Відмова від відповідальності: я є архітектором в гнучкому середовищі , але, як Мольтке каже: «Ні один план битви не витримує контакт з ворогом». Іншими словами, практичність означає, що точної літери керівництва не завжди можна дотримуватися.
Більшість піднятих вище балів дотримуються як найкраща команда. Однак принципу 1 (Командам, що кодують систему проектування системи) насправді важко дотримуватися, коли команда складається з десятків (або сотень) розробників, розбитих на різні континенти та часові пояси . Це не має нічого спільного з навичками або ставленнями розробників, тим більше, що логістична проблема їх усіх присутніх, щоб зібрати вимоги клієнтів та зрозуміти існуючі складні системи.
Отже, як робиться дизайн системи? Використовуєте UML? Або документ, який визначає інтерфейси та основні блоки? Може щось інше?
Часто архітектор ідентифікує основні компоненти, потім визначає інтерфейси між ними (включаючи нефункціональні вимоги, такі як безпека, швидкість та надійність) та делегує внутрішнє проектування компонентів окремим командам . Це хороший компроміс між тим, щоб дозволити командам проектувати власні компоненти, не вимагаючи, щоб усі знали все про систему.
Кожна організація має власний набір стандартів архітектурних конструкцій, і це часом змінюється від проекту до проекту в межах організації. Цей дизайн зроблений до того, як команда розпочне кодування або якомога раніше і зазвичай містить (і не є повним списком):
- Розширені вимоги та визначення сфери застосування. Сюди входять випадки використання чи історії користувачів, які складають бізнес-вимоги вищого рівня. Мені особисто подобається використовувати RFC 2119 для нефункціональних вимог. Дизайн заснований на та відстежується на них. Хоча це може не відповідати загальному визначенню дизайну, вони часто так само важливі.
- Огляд, що складається з мережевої або компонентної діаграми високого рівня та сторінки тексту. Це для дуже широкої аудиторії, від вищого керівництва до розробки та якості. Це рідко використовується UML або визначена нотація через широку аудиторію.
- Деталі про окремі компоненти, часто зосереджуючись на інтерфейсах або API між ними, як згадувалося вище. Інтерфейси можуть бути вказані як підписи методів на цільовій мові з деталями попередньої умови та післяумови. Компоненти можуть мати мережеві діаграми, такі як показ компонування віртуальних машин у хмарі або центрі обробки даних та їх мережеві механізми. Реляційні бази даних, як правило, мають діаграми взаємозв'язок особи.
- Перелік архітектурних ризиків та їх пом'якшення, якщо вони відомі. Як і вимоги, вони демонструють дизайнерські рішення та компроміси.
Коротше кажучи, конструкція системи в умовах спритного процесу точно така ж, як у традиційного процесу водоспаду. Однак у спритних умовах менше дизайну робиться наперед, а більше - делегується командам компонентів . Ключовим є визначення того, наскільки глибоко слід пройти спочатку, які рішення відкласти та визначити, коли рішення потрібно приймати. Рішення, що впливають на декілька команд розвитку, слід приймати раніше, особливо масштабність та безпеку. Такі рішення, як додавання додаткових мов до вже інтернаціоналізованого продукту, можна відкласти до дуже пізнього часу.
Після створення первинного проекту архітектор працює з кожною з команд і переглядає їхні проекти. Якщо для одиниці роботи потрібні додаткові зміни в дизайні чи дизайні (наприклад, спринт спринту), архітектор прагне забезпечити його до моменту початку роботи одиниці роботи. Архітектор також несе відповідальність за повідомлення будь-яких змін постраждалим командам або зацікавленим сторонам.