kafka-jdbc-connector из kafka-connect примерно так и работает. Но когда настраивали рядышком его и дебезиум, последний мне показался более простым в настройке-поддержке.

Какие update? Отдельная таблица событий для кафки, конечно. А как еще?

Да я бы сам написал, без всяких внешних продуктов. Оно и проще и надежнее )

Ивент Шторминг не поможет

Поможет просто Шторминг, групповое интервью

Но на выходе скорее действительно будет лапша

а кто в нее пишет? триггеры? приложение?

Ивент Шторминг может помочь чтобы очертить целевое решение и наметить план разделения макарон

Но не исключено, что нужно будет переписывать всё с нуля

Обычно - приложение в транзакции.
Вообще, все зависит от описания бизнес-логики и от НФТ, если вся логика сделана через workflow, то можно вообще явным образом отправлять.

а каков смысл этой затеи? Ну узнаете что внутри все связанно и очень плохо. Будете его десятилетиями разбивать. Может лучше подумать в сторону того какие важные функции делает приложение и попробовать спроектировать с нуля?

Уточнение: прояснить хотим внутреннее устройство не столько со стороны кода, сколько с продуктово-бизнесовой стороны. Почти никто не помнит что изменение в одном месте влияет на бизнес-функциональность в другом. Такие вещи всплывают на тестировании когда старые тестировщики начинают проверять вот эти вот скрытые связи. Либо уже саппорт говорит, что пользователи о странном поведении сообщают.

Переписать к сожалению не вариант, по крайней мере, на данный момент. Смысл затеи как уже написал — дать возможность новым людям въезжать во внутреннее устройства приложения быстрее, а не за несколько месяцев.

Ну вот да, если приложение пишет - то какая разница ему, в еще одну таблицу или сразу в кафку. Если в транзакции - видимо есть какой-то выигрыш в простоте, в кафку попадает только при коммите. В целом интересная точка зрения, спасибо, но нам переделывать уже немного поздновато))

Тогда то что нужно

На практике оказывается, что они свои процессы не знают

Поэтому два шага:
- восстановить (выявить) процессы
- восстановить архитектуру (как процессы реализованы)

Сейчас интересует первое, да — выявить процессы. Хотя бы чтобы продакты начали нормально фичи описывать (они новые, эти процессы не знают). Архитектура тоже конечно интересна, но уже вслед за этим.
Условно говоря, 3-4 человека из все группы человек в 20 сейчас примерно понимают что и как внутри работает.

И как правило, запущено всё одновременно:
- нет требований, соответственно нет тестов (которые тестируют)
- нет описания бизнес-процессов/вариантов использования, соответственно нет никакой декомпозиции функциональной
- нет управления, разработка в режиме тушения пожаров

Да, всё верно. Шторминг - хороший инструмент, да как и любые воркшопы

Иными словами, если бизнесу не нужно качество, он не хочет ни за что платить, кроме кодирования.

Просто "Шторминг" — это тоже какой-то формат? Почему я спросил об Ивент Шторминге, потому что это приводит к вполне конкретному результату, которым можно пользоваться.
У меня предчуствие, что абстрактное неструктурированное интервью/воркшоп (а собирать структуру такого воркшопа с нуля я не возьмусь) скорее всего приведет к тому, что опишут несколько наиболее простых кейсов, которые лежат на поверхности, и цель в итоге достигнута не будет.
Меня устроят названия и других форматов подобных интервью, подробнее по ним почитаю уже сам.

Если сразу писать и в БД и в кафку, то при сбоях можно целостность потерять.

Шторминг - это мозговой штурм

Я  высылаю опросник, который охватывает разные срезы, от аналитики, до эксплуатации.

Получается итерационно некий документ.

Затем формирую план интервью - и вперёд.

Условно, всегда знаю в каком русле вести интервью.

Но это работает только для восстановления Big Picture

На сегодня для выявления именно бизнес-процессов лучше Ивент Шторминга с моей точки зрения ничего нет

Альтернатива - выявить аналитиков, которые всё же знают процессы и могут их описать

Иногда Шторминг проводить бессмысленно, потому что процессы в голове у одного-двух людей. Нужно просто "посадить" рядом с ними аналитиков.