У архитектуры множество определений. Одно из наиболее емких — представление о компонентах системы и их взаимосвязях между собой. В качестве компонентов могут выступать как достаточно крупные куски системы, например, интернет-банк, мобильный банк, смс-банк, процессинг, так и более мелкие, — компонент по работе с карточными лимитами, модуль конвертации валют, компонент уведомлений.
Разработчикам, явно или неявно, приходится проводить анализ архитектуры для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, с чем будем взаимодействовать новый компонент или на работу каких компонентов может повлиять тот, в который мы вынуждены внести изменения.
Водопадный подход максимально пытался обеспечить целостность архитектуры за счет BDUF/BRUF (Big Design Upfront/Big Requirement Upfront). Это были два грандиозных по своим масштабам этапа — сбор требований и проектирование, плавно перетекающее в детальный дизайн. Выхлопом этапов были железобетонные требования и нерушимый, крепкий как скала дизайн.
В Agile все несколько иначе — мы работаем короткими итерациями, каждая из которых включает в себя и уточнение требований и дизайн и тестирование. BDUF/BRUF не подходит ни под каким углом.
Как же при таком подходе обеспечить целостность архитектуры системы?
Можно попытаться выделить этапы сбора требований и дизайна в отдельную итерацию, но тогда мы теряем гибкость. Еще до начала разработки нужна полная информация для документирования требований и создания архитектуры. Плюс никакой обратной связи от проектирования. И, конечно, полное проектирование – это невероятно долгий процесс.
Здесь нам может помочь «метафора системы». Метафора – это лаконичная концепция системы. К примеру, это могут быть некие визуальные образы. Визуальные образы вообще полезно использовать – они дают цельное представление о системе и улучшают взаимопонимание между участниками проекта.
Метафора системы дает команде представление, общее видение о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты и какую форму они должны принять. При неправильном использовании инкрементального подхода к развитию архитектуры (или недостатка квалификации, зрелости) вполне реальо потерять управляемость с точки зрения разработки, понимания, неверно определить предел системы по производительности или масштабированию.
В качестве примера посмотрим на пазл. Откуда вы знаете, как соединять кусочки? Один кусочек стыкуется с другим и его форма должна идеально подходить к тем, которые к нему примыкают. Но есть нечто куда более важное, чем форма кусочков: картинка. Она и является настоящим путеводителем. Ориентируясь на картинку вы знаете, что в итоге должны получить. Картинка настолько важна, что если у двух соседних кусочков картинки не соответствуют друг другу, то вы точно знаете, что изготовитель пазла ошибся. Это и есть метафора. Большая картинка, собирающая все части пазла воедино. Взгляд на систему, делающий очевидными места и формы отдельных модулей. Если форма модуля не соответствует метафоре, значит модуль не годится.
Задумайтесь над тем, какая метафора подошла бы для вашего продукта, системы. А теперь, каким бы вам хотелось видеть продукт. Сформулируйте, кратко опишите и двигайтесь в направлении метафоры системы вашей мечты.
Один из способов определить архитектурное видение — подход C4 от Simon Brown.
2 comments / Add your comment below