tgoop.com/emacsway_log/1072
Last Update:
Возвращаясь к вопросу, который озвучил @mxsmirnov . Полный контекст вопроса https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=38m20s начинается с 38:20.
Максим обращает внимание на то, что архитектурное решение - это ассоциация в архитектурной модели, причем n-арная.
Иными словами, ассоциации находятся не между ADR, а внутри ADR между мотивационными элементами (требованиями, ограничениями, целями, драйверами, стейкхолдерами и т.д.).
Причем, часто архитектурное решение является результатом разрешения противоречивых или обратно-коррелирующих требований.
Хороший пример приводит Игорь Беспальчук: "Пилоту нужно уворачиваться от зениток, а бомбардиру нужно чтобы вели ровно, чтобы лучше прицелиться. Конфликт неизбежен и успех в поиске баланса."
Другой пример - добавили mtls - повысили безопасность, но ухудшили performance.
Какая причина появления ADR? Как писал сам Michael Nygard https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions , он пытался найти баланс между тяжеловесностью традиционной архитектурной документации и её полным отсутствием в условиях Agile.
О чем это говорит? Почему в Agile требования выражаются чаще всего посредством PBI (Story)? Почему не делают спецификаций и трассировок? Потому что трассировки нужны для предвидения (prediction) последствий решения, в то время как Agile основан на итеративной модели, где основной способ обработки неопределенности осуществляется опытным путем (adaptation). Long read по теме:
- https://dckms.github.io/system-architecture/emacsway/it/sdlc/models/agile/agile.html
- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/balancing-prediction-adaptation.html
Иными словами, Agile был ориентирован на проекты, где создание артефактов для заблаговременного (prediction) разрешения неопределенности путем логического вывода себя не оправдывает экономически, ибо дешевле, как говорится, проверить "методом тыка" (adaptation).
Отсюда вывод - если сам способ выражения требований в Agile (PBI) не обеспечивает трассировки (связи между PBI являются зависимостями, а не трассировками), то и в ADR она и подавно не нужна.
Если мы посмотрим на дату статьи Michael Nygard, то увидим 2011 год. О чем это говорит? Это говорит о том, что в это время на рынке происходит рост сложности и размера среднего проекта. Именно по этой же причине на рынке возникает запрос и на микросервисы, и на гибридные SDLC-модели разработки (цель которых сводилась к снижению доли Adaptation в пользу Prediction). Dean Leffingwell в 2011 выпустил книгу Agile Software Requirements и первый релиз SAFe.
Примерно через пару лет Brandolini изобретает Event Storming, потому, что:
💬 "...iterative development [на тот момент стал - прим. мое] is expensive. It is the best approach for developing software in very complex, and lean-demanding domains. However, the initial starting point matters, a lot. A big refactoring will cost a lot more than iterative fine tuning (think splitting a database, vs renaming a variable). So I'll do everything possible to start iterating from the most reasonable starting point."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini
💬 "Upfront is a terrible word in the agile jargon. It recalls memories the old times analysis phase in the worst corporate waterfall. Given this infamous legacy, the word has been banned from agile environments like blasphemy. But unfortunately ...there's always something upfront. Even the worst developer thinks before typing the firs line of code."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini
Еще через пару лет выходит статья "Insights from 15 Years of ATAM Data: Towards Agile Architecture". ATAM в Agile!!!
Появляется MiniQAW.
Таким образом, был конкретный рыночный запрос на рост доли Prediction в обработке неопределенности в силу роста размера среднего проекта на рынке, который Michael Nygard пытался решить путем введения компромиссной формы документирования, о чем он сам же и говорит.
Продолжение следует...
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1072