ITRampage

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

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

Архітектори на полі бою

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

Це також дозволяє значно покращити процес навчання та підвищити рівень команди розробників, що у перспективі дозволить рости й самому архітектору, оскільки врешті решт команда буде здатна самостійно виконувати більшу частину попередніх обов’язків архітектора, а сам архітектор зможе піднятися на більш високі рівні, наприклад з Software/Solution Architect до рівня Enterprise Engineer, Engineering Manager, CTO. Ця тактика відкриває можливість для іншої тактики – вирощування кадрів всередині компанії, замість того, аби запрошувати на керівні посади людей з вулиці/по оголошенню, які не є неформальними лідерами та погано розуміють внутрішню кухню.

Архітектура вбудована у код (Architecture Built in Code – ABiC)

Друга тактика, яку я хочу порадити та розвинути як повноцінну методологію – це застосування підходу, який я називаю Архітектурою вбудованою у код (Architecturee Built in Code – ABiC (це акронім, читається як “Єй-Бі-Сі”)). Не плутайте з Acrhitecture as Code (AaC). Відмінність дуже значна!

AaC, по суті є комбінацією CI з fitness-функціями для перевірки відповідності архітектурі та підходу Diagrams as Code (PlantUML, Structurizr та інші). Також AaC вимагає досить складної інфраструктури, а все аби архітектор не працював із кодом самого рішення.

В ABiC я пропоную взагалі відмовитися від архітектурних артефактів (вони можуть врешті решт бути згенеровані автоматично), а сфокусуватися на сумісній праці архітекторів з командами розробників. Підхід ABiC тісно пов’язаний з низьхідною (Top Down) розробкою. Найвищі рівні (фреймворк/каркас) будує архітектор, а вже розробники займаються реалізацією деталей розміченої у коді архітектури. Аналогією для цього підходу може служити розмальовка, де архітектор створює власне саму розмальовку, а розробники її розфарбовують. Цьому аспекту ABiC я дав назву Архітектура як фреймворк (AaaF – Achitecture as a Framework).

Архітектура як фреймворк (Architecture as a Framework – AaaF)

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

Тим, що фреймворки використовують наш код вони нав’язують нам те, як код має бути структурований. Наприклад, коли говорять про MVC фреймворк, накшталт Ruby on Rails, то мають на увазі, що розробник має створювати такі компоненти, як моделі (сутності!), контроллери та відображення, які, зазвичай, мають бути організовані у певному дереві директорій, аби фреймворк міг, користуючись принципом CoC (Conventions over Configuration), знайти та поєднати ці шматки у власне застосунок/програмне рішення.

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

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

Звичайні фреймворки (якщо не брати бібліотеки для маршрутизації з “батарейками у комплекті”, як то Sinatra в Ruby чи Gin або Gorilla в Golang)) мають досить велику кодову базу, яка зовсім ніяк не стосується бізнесу. Звичайні фреймворки – це дуже товсті прошарки клею, що поєднує компоненти, розроблені командами того чи іншого проєкту. Такі фреймворки мають значний негативний вплив на ефективність, достатньо високий вхідний поріг та вимагають постійний витрат на перехід на новіші версії. Структура компонентів у таких фреймворках ніколи не відображає моделі предметної області та навіть заважає чи унеможливлює якісну модуляризацію кодової бази.

AaaF позбута всіх перерахованих недоліків і відповідно:

• Не має (або має незначний) негативний вплив на ефективність;
• Якісно відображає модель предметної області;
• Має низький вхідний поріг і може бути освоєна новачком за день;
• Не потребує оновлень, що не пов’язані з оновленнями власне бізнес моделі;
• Складається із коду, який вирішує проблеми бізнесу;

Це тільки загальні нариси того, як я бачу якісні розробку та сумісну роботу архітекторів з розробниками. Я поки що тільки працюю над формулюванням ABiC та AaaF і буду час від часу ділитися своїми напрацюваннями на цьому напрямку, які, можливо, згодом навіть вильються у книгу.