Это уже антипаттерн микросервисов, и это тот случай, когда не думали об интерфейсах.

думали, но не то придумали, но гордо можно заявлять о микросервисной архитектуре

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

я немного не про это говорю, я хочу сказать, что в микросервисах эти интерфейсы более явные и их сильно сложнее менять, поэтому о них больше думают и больше вероятности, что они остаются в приличном виде в процессе заговнокоживания проекта. И это всё не значит, что любой проект будет хорошим, нет. Просто он будет чуть лучше в типичной ситуации.

При прочих равных, микросервисный проект все таки более сложное дело

когда-то?народ до сих пор то и дело норовит любую задачу начать с вопроса "а какая у нас будет структура табличек в БД". Инерция мышления, как она есть

на предыдущем месте работы такое было - проект был в одном вебдомене, вырос, его стали делить, наплодили репок и вебморд, и они продолжили ходить в бд самого старого проекта. и при этом между ними ещё rest api какое-то было.
Но и это ещё не всё. В компании было соглашение, что бизнес-аналитики своим софтом могут подключиться к любой базе любого проекта и сделать из неё выборки. А значит у таблиц должны быть определённые поля и вообще при миграциях нужно всё это учитывать чтоб нигде на стороне ничего не сломалось.

Хороший код с первой попытки не получится. Нужно выкатить в прод, посмотреть. Потом переписать заново с нуля, на основании полученного опыта. Выкатить в прод, посмотреть. И где-то после 3-4-го переписывания с нуля получится хороший код. Это стоит дорого, поэтому хороший код встречается редко.

вот вот

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

Такова жизнь.

Я с этого и начинал, хотите хорошего кода, переписывайте!

Брукс еще в 75-м прошлого века это писал.

А почему тогда бизнес так негативно к этому относится? :))

Они не мыслят категориями "хороший код/плохой код". Нет такой метрики.

переписывать — это решение, это понятно, но это время и деньги. Вопрос в том как уменьшить кол-во этих переписываний? Какие для этого можно использовать практики/инструменты.

Никак не уменьшить, в том-то беда. Фундаментальное западло индустрии.

Хуйня это все

Ну и инженерной деятельности вообще

Хороший код - это код который легко переписать