Тут нельзя привести точной меры в виде если у вас 1К строк кода это еще нормально, а 1001 это уже монолит. Нет, мерой скорее является тот момент, когда вы начинаете все более активно применять различные шаблоны проектирования.
Спорное утверждение. Одна из проблем монолита не в объёме и сложности кода, а в том что при росте команды качеством этого кода становится трудно управлять, не пересекая границ субдоменов. Я не очень понимаю причём тут разделение приложения на модули и применение шаблонов проектирования. Это не признак того, что срочно нужно пилить микросервисы. Если у вас в команде три калеки, нет отряда тестировщиков и девопсов, то распил на микросервисы приведёт приложение к распределенному монолиту. Даже если изначально вы его задумаете красивым и каноничным (как в книжке Криса Ричардсона)... Возможно у вас уже сформировалась куча команд, которым стало тесно в одном проекте, но про это как раз в статье ничего нет... Если проект делает 1-2 команды, то возможно проблему бы решил основательный рефакторинг, а не радикальные меры с разбиение приложения на десяток сервисов. ИМХО, решение о переходе к микросервисам должно приниматься только в том случае, если вы к нему организационно готовы и только после этого задумываться об окончательной архитектуре.
Тут нельзя привести точной меры в виде если у вас 1К строк кода это еще нормально, а 1001 это уже монолит. Нет, мерой скорее является тот момент, когда вы начинаете все более активно применять различные шаблоны проектирования.
Спорное утверждение. Одна из проблем монолита не в объёме и сложности кода, а в том что при росте команды качеством этого кода становится трудно управлять, не пересекая границ субдоменов. Я не очень понимаю причём тут разделение приложения на модули и применение шаблонов проектирования. Это не признак того, что срочно нужно пилить микросервисы. Если у вас в команде три калеки, нет отряда тестировщиков и девопсов, то распил на микросервисы приведёт приложение к распределенному монолиту. Даже если изначально вы его задумаете красивым и каноничным (как в книжке Криса Ричардсона)... Возможно у вас уже сформировалась куча команд, которым стало тесно в одном проекте, но про это как раз в статье ничего нет... Если проект делает 1-2 команды, то возможно проблему бы решил основательный рефакторинг, а не радикальные меры с разбиение приложения на десяток сервисов. ИМХО, решение о переходе к микросервисам должно приниматься только в том случае, если вы к нему организационно готовы и только после этого задумываться об окончательной архитектуре.