это толстая тема) все зависит от талантов разработчиков, чем меньше сервис - тем лучше

некоторое время тратится на скан класпаса, если правильно указать пакеты(указал org - ну ссзб), то это даже меньше секунды. настоящим прожором является jpa и хибер, он очень долго сканирует и строит метамодели, потом идет валидировать схему, вот он может уйти в минуты. mvc без jpa будет секунды 3 (опять таки зависит от фанатизма), вебфлакс может  и меньше секунды (ибо там нетти, а не томкат, который как раз таки и притормаживает mvc)

дальше опять таланты разработчиков, кто-то на старте папку с xsd начинает в кэш загонять, кто еще чего

подключаешь камунду с парой десятков процессов, привет минуты 2-3 старта

ничего он не генерит, если не попросить (runtime weaving), а так там создаются объекты-прокси, на них времени много не надо

Ну я хз как так, но время старта спрингбута и кваркуса с jpa/hibernate, кафкой и рестом на борту отличается в разы, причём может в 2 раза, а может и в 5.

с кваркусом не работал, но у нас время старта устраивает

кроме модуля с камундой

Кто-нибудь практикует Architecture decision record? Можете поделиться опытом? Это «внутрення кухня» или этот процесс предполагает фидбэк и согласование с заказчиком?

У нас внутренняя. Разве что новые технологии требуют согласования.

Интересно про реальный опыт ADR:
* где храните? как разбито/структурировано?
* если прорабатывается тема, в которой, условно, 20-30 архитектурных решений (большая статья с элементами дизайна) - как это оформляете в стиле ADR?
* какие преимущества ощущаете по сравнению с просто архитектурной документацией в Wiki?

1. Храним в wiki, не структурируем.
2. Такого быть не должно, ADR не про описание архитектуры, а про решения в процессе.
3. Это разные артефакты. ADR - как и почему решили, это про историю принятия решения. Арх.документация - как все устроено.

У нас два потока ADR - на всю компанию (типа принятие в стек новой технологии) и внутри проекта (решили использовать такой-то стиль написания yaml)

1. так же.
2. в ADR есть ссылки на варинаты решений, и на решение которое принято (но внтури ADR нет документации - только контекст и факт решения)
3. наоборот удобнее когда и архитектурная документация и ADR в одной системе (вики), т.к. ссылать друг на друга приходится.

3. У нас тоже все в Вики. Разные артефакты - но одна система

Стиль написания yaml - это я понимаю, супер-важное решение. А вот все-таки если что-то более комплексное. Ну, не знаю, например, "как у нас будет устроена поддержка многоязычности". Большая тема. Описание. Что с хранением, что с интерфейсами, что с сессиями, что с переключением, что с ошибками, что с переводчиками. 20-30 арх-решений. Как они у вас в ADR будут отражаться? Один раз собрались, приняли финальный дизайн после серии обсуждений - это будет одна запись ADR? Или как?

На мой взгляд ADR для другого: зафиксировать принятые решения и их мотивацию. Главное - мотивация. Это ответ на вопрос “почему” были выбраны эти решения. Простое описание архитектуры декларирует факты что вот так-то должно быть сделано, но не отвечает на вопрос почему именно так. Спустя пару лет, новые люди будут спрашивать почему были приняты такие решения и ответ вы найдете в ADR.

"Простое описание архитектуры" конечно же, по всем нормам (книжкам и стандартам) фиксирует в т.ч. мотивацию (Rationale).

Но действительно, старые документные традиции плохо фиксировали процесс согласования и принятия решения - типа, на титульном листе талмуда кто и когда утвердил. Это, конечно, waterfall.

ADR по идее, должен отражать историю работы над архитектурой лучше.
Но у меня возникают вопросы типа тех, что я привел выше.
Если кто-то практикует ADR только в том духе, что "раньше мы не описывали обоснования арх-решений, а с ADR - стали записывать", я это могу понять, так бывает много с чем, но преимуществ ADR я в этом никаких не вижу, я и без всяких ADR прекрасно записываю обоснования. Хотелось бы понять поэтому, кто же что получил от ADR.
Ну, и пока я так и не понял, как построена работа с комплексными решениями в ADR.

Ну, или yaml или json. Но оно сильно важное, так как они несовместимы друг с другом или с разными библиотеками и это общее решение для проекта из нескольких компонент или даже команд.