вопрос не в том как делить, а в том когда это физически выносить в разные репы (или может изначально под каждый чих пилить свой репозиторий)

в зависимости от того что ты пишешь и как тебе по структуре удобно

К сожалению я ещё не дочитал до 4 части, где вводятся такие понятия, как "ограниченный контекст" и "ядро". Интуитивно понятно о чём речь, но возможно когда дочитаю - что-нибудь ещё прояснится.

Правильно я понимаю что вы рекомендуете придерживаться правила: 1 доменная модель = 1 git репозиторий?

про первый пункт тогда обратный вопрос. как относитесь к объединённым в одном репозитории фактически разным проектам. например бэк и фронт. или что-то базовое и абстрактное, а рядом несколько разных реализаций (например со спецификой интеграции под разные платформы)

Зависит от проекта, если бэк и фронт вместе и это не BFF (backend for frontend) то негативно

весьма категорично. может всё-таки в этом есть смысл например на старте проекта, когда API ещё не вполне сформирован? или может вообще есть смысл отделять что-то в отдельный репозиторий только при достижении первой стабильной версии (v0.0.1) для публикации этого модуля.

Смысл тогда делать вместе, если в последствии все равно будете отделять ?

Лучше сразу делать правильно и учитывать дальнейшие риски, мало ли хитрые бэкэндеры захотят спрятать какие нибудь ключи от фронтдеров 🫡

интуитивно с вами хочется согласиться, но я не могу достаточно формально ответить себе на вопрос "почему?". почему не начать с монолита который очевидно быстрее и проще сваять на старте, а потом итеративно дербанить его на модули?

Потому что в процессе деления может уйти больше времени, что бы заменить все импортируемые файлы на модули

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

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

Сколько людей столько и мнений, лично настрадался с саб модулями когда делил уже «готовый»проект на модули, было тяжело и больно 🫡

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

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

ну почему никто? мы на работе активно используем.

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

какие например? что-то ничего не приходит в голову.

навскидку наверное могу назвать только gyp