Цена архитектурных решений
Многие задаются вопросом, какие решения являются архитектурно значимыми. Но как оценивать их критичность, зачем учитывать обратимость и почему всё это особенно важно сейчас?
М. Нейгард говорит, что значимые решения влияют на структуру, нефункциональные свойства, зависимости, интерфейсы (API), технологии разработки. Однако М. Ричардс и Н. Форд уточняют: решения являются архитектурными тогда, когда нацелены на поддержание важных архитектурных свойств (например, масштабируемости). Без привязки к этому выбор любой технологии – это не архитектурное решение, тем более значимое.
Знакомство с разными кодовыми базами заставило меня посмотреть на это с ещё одной стороны. При изучении системы часто полезно двигаться от понимания предметной области к технической реализации и организации её сопровождения. Это позволяет выделить три взаимосвязанных измерения – уровня:
1️⃣ Предметное. Что и зачем система должна делать? Инварианты, процессы, бизнес-правила.
2️⃣ Техническое. Как система реализует необходимое поведение? Архитектура, интеграции, данные, код.
3️⃣ Организационное. Кто и как обеспечивает её развитие и работу? Владение, процессы, эксплуатация.
А теперь самое важное:
Ошибки, допущенные на верхних уровнях, часто мультиплицируются на последующих, образуя лавинообразный эффект.
Ошиблись при моделировании, неправильно определив статусную модель и отношения между агрегатами и сущностями – обрекли на страдания всех: реализацию, код, службу поддержки и пользователей. Технически корректная реализация воспроизводит ошибочную бизнес-модель.
Однажды выбрали хореографию, потому что так было проще в начале реализации проекта, но при усложнении бизнес-процессов вовремя не перешли на оркестрацию – получили запутанный код, ломающийся при каждом изменении, и бесконечную нагрузку на операционную команду, обречённую на решение проблем с согласованием данных из-за некорректного завершения бизнес-процессов.
Разумеется, последствия распространяются не только сверху вниз. Неверное техническое решение может оказать куда большее влияние, чем небольшое изменение модели. Например, выбор способа хранения, транзакционных границ, стратегии отказоустойчивости.
Таким образом, проблемы возникают не только из-за ошибочных решений, но и из-за решений, которые когда-то были правильными, однако продолжили применяться после изменения исходных предпосылок.
Значимость архитектурного решения определяется не только тем, что оно затрагивает, но и масштабом возможных последствий, стоимостью изменения и обратимостью. Уровень решения помогает оценить потенциальную область распространения его последствий, но не определяет значимость автоматически.
Такой подход полезен и при оценке критичности технического долга, например во время приёмки существующего проекта.
При этом обратимость нужно рассматривать как критерий критичности решения. Одновременно необратимость – это не что-то плохое, но иной уровень ответственности и контроля. Некоторые изменения можно безопасно откатить, другие дорого, третьи невозможно. Поэтому наряду с критериями пересмотра в ADR полезно фиксировать возможность и стоимость обратимости.
Возвращаясь к началу: почему это важно сейчас? Многие задачи адресуются ИИ, команды начинают перестраивать разработку через SDD-подобные решения. При делегировании ИИ важен не столько технический уровень задачи, сколько масштаб последствий решений, которые ИИ получает право принимать самостоятельно. Следовательно, нужны более чёткие критерии того, что можно делегировать ИИ, а за что и как придётся держать ответ самому.
А теперь подумайте и спросите себя, какого уровня решения за вас недавно принимал ИИ? Определены ли границы этих решений и как они контролируются. 😏
#arch #view
Многие задаются вопросом, какие решения являются архитектурно значимыми. Но как оценивать их критичность, зачем учитывать обратимость и почему всё это особенно важно сейчас?
М. Нейгард говорит, что значимые решения влияют на структуру, нефункциональные свойства, зависимости, интерфейсы (API), технологии разработки. Однако М. Ричардс и Н. Форд уточняют: решения являются архитектурными тогда, когда нацелены на поддержание важных архитектурных свойств (например, масштабируемости). Без привязки к этому выбор любой технологии – это не архитектурное решение, тем более значимое.
Знакомство с разными кодовыми базами заставило меня посмотреть на это с ещё одной стороны. При изучении системы часто полезно двигаться от понимания предметной области к технической реализации и организации её сопровождения. Это позволяет выделить три взаимосвязанных измерения – уровня:
1️⃣ Предметное. Что и зачем система должна делать? Инварианты, процессы, бизнес-правила.
2️⃣ Техническое. Как система реализует необходимое поведение? Архитектура, интеграции, данные, код.
3️⃣ Организационное. Кто и как обеспечивает её развитие и работу? Владение, процессы, эксплуатация.
А теперь самое важное:
Ошибки, допущенные на верхних уровнях, часто мультиплицируются на последующих, образуя лавинообразный эффект.
Ошиблись при моделировании, неправильно определив статусную модель и отношения между агрегатами и сущностями – обрекли на страдания всех: реализацию, код, службу поддержки и пользователей. Технически корректная реализация воспроизводит ошибочную бизнес-модель.
Однажды выбрали хореографию, потому что так было проще в начале реализации проекта, но при усложнении бизнес-процессов вовремя не перешли на оркестрацию – получили запутанный код, ломающийся при каждом изменении, и бесконечную нагрузку на операционную команду, обречённую на решение проблем с согласованием данных из-за некорректного завершения бизнес-процессов.
Разумеется, последствия распространяются не только сверху вниз. Неверное техническое решение может оказать куда большее влияние, чем небольшое изменение модели. Например, выбор способа хранения, транзакционных границ, стратегии отказоустойчивости.
Таким образом, проблемы возникают не только из-за ошибочных решений, но и из-за решений, которые когда-то были правильными, однако продолжили применяться после изменения исходных предпосылок.
Значимость архитектурного решения определяется не только тем, что оно затрагивает, но и масштабом возможных последствий, стоимостью изменения и обратимостью. Уровень решения помогает оценить потенциальную область распространения его последствий, но не определяет значимость автоматически.
Такой подход полезен и при оценке критичности технического долга, например во время приёмки существующего проекта.
При этом обратимость нужно рассматривать как критерий критичности решения. Одновременно необратимость – это не что-то плохое, но иной уровень ответственности и контроля. Некоторые изменения можно безопасно откатить, другие дорого, третьи невозможно. Поэтому наряду с критериями пересмотра в ADR полезно фиксировать возможность и стоимость обратимости.
Возвращаясь к началу: почему это важно сейчас? Многие задачи адресуются ИИ, команды начинают перестраивать разработку через SDD-подобные решения. При делегировании ИИ важен не столько технический уровень задачи, сколько масштаб последствий решений, которые ИИ получает право принимать самостоятельно. Следовательно, нужны более чёткие критерии того, что можно делегировать ИИ, а за что и как придётся держать ответ самому.
А теперь подумайте и спросите себя, какого уровня решения за вас недавно принимал ИИ? Определены ли границы этих решений и как они контролируются. 😏
#arch #view
Просмотры: 3