Выполняю задание третьего раздела Системной инженерии «Непрерывное принятие архитектурных решений». Где просят описать какой-нибудь архитектурный паттерн из предметной области.
А я хотел бы прежде этого немного поразмышлять на новое понимание архитектуры. И прихватить классическое ТЗ на Опытно-конструкторскую работу. Вот мы тут недавно такой документ вспоминали в соседнем посте: ХАОС - #3 от пользователя bodrov-vk
Да и, в принципе, люблю я ТЗ обсуждать, делал домашнее задание по онтологике на его примере: Онтологический дребезг в ТЗ на ОКР
В ТЗ на ОКР нормативными документами требуется внесение целой кучи требований -остей. Безопасность, надёжность и т. д. Раньше мы считали их ограничениями. Т. к. они ограничивают нас в конструктивных реализациях заказанного функционала. В принципе, они таковыми и остаются, но теперь мы понимаем их как архитектурные решения архитектора надсистемы. Понятно откуда разно-направленные намерения прикладного разработчика и архитектора.
Но что даёт нам новое понимание архитектуры? Что раз это архитектурное решение, то давайте нам rationale/объяснение его необходимости. Покажите нам развилку/trade off которая осталась за выбором. Опять таки выводим на обсуждение, может быть не такая уж это была и развилка?
Описание архитектурного паттерна
А теперь, собственно к заданию. Пока читал эту главу, у меня где-то на границах сознания крутились всякие профильные конференции. Когда разработчики рассказывают пост-мортемы своим проектам, всегда как раз вспоминают развилки. И это носит такой характер байки-анекдота. Отсюда и название поста. Но вот после прочтения главы теперь понятно, что это тоже такой мем-паттерн архитектурного описания. Раньше относился к этому именно как к анекдотам, что сколько проектов, столько и развилок. Как-то не системно их все запоминать. Но чем больше работаю, тем больше вижу что есть повторяемость. Есть паттерн.
- Имя паттерна — Вот тут затрудняюсь, есть ли тут устойчивое название. Но ситуация ровно такая же, как когда обсуждают «монолит» и «микросервисы». Можно железную систему собрать с tight coupling, а можно с loose.
- Тип — Отношения модулей
- Ситуация/context — При проектировании разбивки системы на конструктивные подсистемы
- Проблема — Если связи слишком тесные/tight полученную систему будет сложно модернизировать, отдельные модули будет сложно переиспользовать в других экземплярах системы. Также растут затраты на испытания. Работы с подсистемами трудно изолировать. В целом все проблемы «монолита» в софте.
- Соображения/влияния/силы/forces — Тесные связи могут сократить время до первого воплощения системы, и в целом можно получить выигрыш по функциональности в ран-тайме. Тесные связи снижают накладные расходы вычислителей за счёт снижения дублирования на проверках входа/выхода. Но в дизайн-тайме они вызывают все описанные выше проблемы.
- Решение — Сделать разбивку на модули согласно существующим ресурсам команды. Обратный манёвр Конвея.
- Последствия — Связи внутри модуля остаются тесными, но между модулями более свободными. Каждая автономная команда может итерировать систему самостоятельно без согласования с прочими командами. Негативные последствия — дополнительная административная нагрузка на системного инженера всей системы по оркестрации между модулями. Согласование протоколов взаимодействия. Не факт, что выбранная разбивка будет отражать принятые в культуре модули. (Какая-нибудь подсистеме будет выглядеть как «монолит» меньшего масштаба по сравнению с модулями на рынке)
- Известные использования — На данном этапе мышления письмом сложилось впечатление что я описываю не паттерн.
Вроде бы трейд-офф между связанностью модулей это классический трейд-офф при разработке.