tgoop.com/emacsway_log/1073
Last Update:
В предыдущем посте мы установили, почему ADR не содержит трассировок - за ненадобностью в своем историческом контексте ввиду того, что они создавались для такой SDLC-модели, в которой преобладает эмпирический способ обработки неопределенности (adaptation), в то время как трассировка больше нужна для заблаговременного способа обработки неопределённости путем логического вывода (prediction).
Исторический контекст появления ADR сопровождался ростом размера среднего проекта на рынке, численностью команды (и команд) его разработки, ростом доли scaled agile и гибридных SDLC-моделей, появлением новых практик заблаговременного разрешения неопределенности. Выделим важное - маятник Prediction/Adaptation двигался в сторону Prediction. Очень хорошо этот момент отражается в Open Agile Standard:
💬 "When combining intentional and emergent architecture, decisions that come from intentional architecture may change. New ones are added and past decisions can be reversed. Therefore, it is important to document the motivations behind past decisions. An Architecture Decision Record (ADR) provides an Agile and lightweight way of doing this."
-- "Open Agile Architecture™ :: 5.2. Architecturally Significant Decisions"
Обратите внимание на фразу "intentional [Prediction] architecture may change [Adaptation]". Эта фраза хорошо выражает причины появления ADR.
На рынке сложилась ситуация, когда на среднем рыночном проекте без архитектурной документации уже нельзя, а с полновесной архитектурной документацией еще нельзя. Эта ситуация привела к появлению ADR, Event Storming, C4 Model и других легковесных практик intentional architecture.
По правде говоря, существуют инструменты, способные создавать связи между ADR, например, https://github.com/npryce/adr-tools
Практической пользы от них немного, поскольку ассоциации находятся внутри ADR, а не между ADR. Архитектурное решение само по себе является ассоциацией.
Из всех архитектурных артефактов я чаще всего на практике применяю мотивационную диаграмму и Event Storming в терминах C.1.10. Business Process Cooperation Viewpoint.
Вообще говоря, предпочитаемые мною методы документирования архитектуры описаны в
https://publications.opengroup.org/g20e
При поиске компромисса, разрешении противоречий требований, особую важность играют связи влияния. Причем, на требования могут влиять конструктивные ограничения самой системы.
И вот теперь я позволю себе переформулировать вопрос, поставленный Максимом Смирновым. Agile за это время изменился. Если раньше преобладали single-team модели, то сегодня - scaled agile. Стремительно увеличилась доля гибридных SDLC-моделей разработки на рынке, в коллективах разработки появились выделенные роли аналитиков и архитекторов, работа с требованиями обрела полноценный характер, стали популярны системы управления требованиями. Сохранил ли при этом формат ADR, предложенный Michael Nygard, свою актуальность? Не пора ли добавить ему полноценную поддержку ассоциаций?
Если мы посмотрим на шаблоны ADR, то мы увидим следующее (продолжение следует):
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1073