Можно и не переписывать - k8s всё равно поднимет сервисы, упавшие с OOM. 😅

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

Но кто поднимет k8s 🤔

безос

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

иногда такой вариант оказывается оправданным (по соотношению полученный результат/затраты)

Ключевое слово - иногда.

Попробую чуть пояснить свои представления.
Сразу скажу, я нефига не понимаю в проектировании самолетов (т.е. систем класса L), так что пишу про всякие финтех (который весь довольно простой, т.е. про класс D (по Коуберну).

Вот у вас есть какая-то живая система. Она всегда находится в состоянии изменения, всегда в ней что-то переписывается.
Текущий срез - это что у нас сейчас в кодовой базе.
Первая производная - что мы сейчас переписываем (текущий поток изменений кода)
Tradeoff (критическое изменение) - это принятие решений, что и куда переписывать
Критерии выбора - это как мы понимаем, как принимать решения по tradeoff (вторая производная)
Архитектура - это как мы меняем эти критерии выбора (т.е. как мы понимаем, где и когда перейти от оркестрации к хореографии, например).
DDD, в этом смысл - вполне себе часть архитектуры, она отвечает на вопрос, как мы меняем критерии выбора для tradeoff при изменении внешнего мира.
Микросервисы как процесс разработки - это еще не архитектура, а просто инструмент для архитектуры.

В микросервисном подходе одна фича - один сервис )

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

Нано сервисы внедрять. По сервису на фичу. Инфраструктура она же бесплатная. А можно говорят ServerLess сделать. Там говорят вообще сервера не нужны. А там и до NoCode не далеко. А нет кода, программисты не нужны. А нет программистов, и тимлиды не нужны. Круг замкнулся.

Обычно написать нормально с первого раза вообще не возможно, только с третьего.
Слишком много неизвестных в первом решении.

Насколько я понимаю, это широко распространённое заблуждение - размер микросервиса может быть любым.

И вот правило "до трех не обобщаем" - это как раз уже архитектура )

У вас возможно неверное восприятие микросервисов

Я про процесс разработки на микросервисах. Так-то слово "микросервис" не имеет смысла само по себе.

Микросервис это определенный контекст, домен знаний а также и связанный бизнес-процесс. Фича-микросервисы попахивают distributed monolith

Т.е. микросервис - это инструмент организации процесса разработки в первую очередь.
Так же, как SOA, например.

+

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