К основному содержимому
к выпуску
Конспект выпуска2023Fellow

Building Evolutionary Architectures — выпуск 3

Клуб продолжает читать Building Evolutionary Architectures и в третьем эфире берётся за вторую часть книги. Ведущие — Александр, Вова и коллеги — зовут гостя Сергея Баранова, и разговор идёт от фитнес-функций и генетических алгоритмов к спору про connascence, к архитектурному кванту с брокером внутри и к переиспользованию как трансплантации органов.

Code of Architecture · книжный клуб7 минут

Конспект сокращён относительно полного выпуска; примеры и оценки передают опыт и позиции участников.

Основная линия материала
01

Фитнес-функции из генетических алгоритмов

Сергей Баранов подключается через несколько минут после старта, представляется коротко — разрабатывает на Java, шутит, что не умеет ни мобильную разработку, ни фронтенд, — и отдаёт рассказ, который готовил ещё к первому эфиру. Термин «фитнес-функция» он встретил, когда расписывал генетические алгоритмы: это мера приспособленности решения к меняющемуся контексту. Человек ест что угодно и живёт при разных температурах, но если температура изменится слишком быстро, он не выдержит; функцией будут количество кислорода и температура, при которых он выживает. Архитектурная фитнес-функция — такой же набор определяющих параметров: скорость выпуска функциональности, производительность, стоимость решения. Сложность в порогах: с какого уровня начнут уходить клиенты, как измерить безопасность, почему тестов должно быть сто процентов зелёных, если при девяноста девяти продукт не умирает. Сергей предлагает доводить параметр до предела — деградация на десять процентов не убивает, а на семьдесят убивает, потому что система перестаёт отвечать.

Параметров при этом должно быть немного. В генетических алгоритмах их бесконечное количество, тысячи и миллионы, а в архитектуре стараются выделить не больше десяти, потому что они конфликтуют: абсолютно безопасный банк — тот, куда нельзя зайти, абсолютно удобный — тот, куда заходит кто угодно; время отклика меньше секунды спорит с требованием шифровать весь трафик. Первая трудность — понять, какие параметры важны, не убивая ради этого приложение; вторая — нормализовать их, чтобы сравнивать производительность с безопасностью. В собственной модели Сергея, похожей на Life, у видов животных были параметры, менявшиеся случайно, и на выживание одного поколения порой уходили сотни миллионов мутаций: из тысячи выживали пять, следующая тысяча оставляла уже совсем других. Отсюда вывод, который он переносит на архитектуру: жизнеспособных решений условно неограниченно много, синхронное взаимодействие или асинхронное — неважно, пока они удовлетворяют фитнес-функции.

02

Connascence, каплинг и локальность изменений

Саму главу авторы уже в первом абзаце сводят к связанности, и разговор упирается в connascence — слово, которое никто из участников не берётся переводить на русский. Александр говорит, что встретил его раньше в другой книге и решил оставить как есть. Определение выписывают так: между двумя компонентами есть connascence, если изменение в одном требует изменений в другом, тогда как каплинг — это любые зависимости, которые менять не заставляют. Возражение появляется сразу: connascence of type — это просто coupling of type, и с naming и position то же самое. Термин, по словам участников, предложили в девяностых, называют 1993 год и объектно-ориентированный дизайн, но за точность никто не ручается; известен он в основном по сайту, который, по ощущению участников, выпадает одним из первых в поиске «чем connascence отличается от каплинга». Вспоминают и бритву Оккама: если хватает более простой модели, более сложная не нужна.

Главу разбирают жёстко: девяносто процентов перечисленных в начале видов каплинга дальше нигде не встречаются, а сама она собрана из других книг тех же авторов и немного из Эванса, выводов же про собственно эволюционную архитектуру в ней почти нет. Для сравнения приводят книгу Влада Хононова по DDD, где все развешанные ружья выстреливают: связь по времени, по операции, где болит и как это переписать; его же книгу про каплинг ждут в этом году и собираются позвать автора с вопросами. Полезной участники называют локальность. Изменения делят на локальные, нелокальные и архитектурные и добавляют, что бывают ещё локальные архитектурные, а хорошая архитектура стремится к максимуму локальных. Худший случай — сильная связь, растащенная по всей системе: можно сломать компонент, о котором никогда не слышал. В одной главе, замечают участники, сошлись bounded context, квант, connascence, каплинг и микросервисы — смело и похоже на маркетинг: не понял главу, иди читать следующую книгу.

03

Квант, брокер и орегонская грибница

Архитектурный квант определён как независимо поставляемый артефакт с высокой функциональной связностью, высоким статическим и синхронным динамическим каплингом; последняя часть определения, по словам одного из ведущих, вызывает больше всего вопросов везде, где он видел обсуждения, включая работу. Микросервис авторы называют идеальным квантом, и Сергей уточняет: если поставка не автоматизирована, а границы проведены не по предметной области, это просто сервисное решение, которое назвали микросервисом и теперь жалуются, что оно падает. База за сервисом входит в квант — без неё сервис не поднимется. Спорят про брокер: в общем кластере с условными двумя сотнями топиков данные разных сервисов не пересекаются, но одна изменённая настройка ломает всех. Сергей отвечает, что смотреть надо на блокирующие зависимости: синтаксическая и семантическая связь через сообщения остаётся, но менять сервисы одновременно не приходится, и брокер как раз разрывает блокирующий каплинг. Отдельно перечисляют виды изоляции — по предметной области, состоянию, времени, сбоям и пространству, — за которыми стоят асинхронность, service discovery, circuit breaker и bulkhead.

Границы кванта всё равно кажутся размытыми: операционную систему авторы явно называют отдельной статической зависимостью, а куда относить кластер оркестратора и виртуализацию — непонятно. Отсюда отступление про грибницу в орегонском лесу, которая, по словам участника, занимает больше восьмисот гектаров, живёт почти две с половиной тысячи лет и генетически остаётся одним организмом: в терминах книги это один квант. Итог — все модели неправильные, но некоторые полезны. Лучшей цитатой главы называют сравнение переиспользования с трансплантацией органов, а не со сборкой из Lego: код никто не готовил к повторному использованию, сервис для кредитов физлицам не заработает так же на юрлицах, а чем код переиспользуемее, тем менее он пригоден. В финале спорят про дата-продукты: деплоить их можно независимо, но авторы кладут их в один квант с сервисом и вводят «кооперативный квант». Один из участников объясняет это тем, что источник данных всё равно один, а дата-продукт — просто ещё один интерфейс, только интегрируются с тобой, а не ты. Под конец ведущие признают, что достают из этой книги меньше обычного, и предлагают поставить книги этих авторов на паузу в голосовании.

Выводы

Что стоит унести с собой

  1. 01Фитнес-функцию задают порогом, а не пожеланием: параметр доводят до значения, за которым система перестаёт быть жизнеспособной, и держат таких параметров не больше десяти.
  2. 02Connascence описывает связи, где изменение одного компонента вынуждает менять другой, а каплинг — любые зависимости; внутри границы связность максимизируют, между границами минимизируют.
  3. 03Дублировать код между сервисами дешевле, чем заводить блокирующую зависимость: опасно дублирование смысла, когда одна бизнес-транзакция размазана по двум сервисам.
  4. 04Огромный пласт аналитической работы, по наблюдению Сергея, уходит на раскопки каплинга: бизнес-процесс, размазанный по десятку систем, каждая новая команда раскапывает заново.

Источники