Виталий Пасюта

Я бы не противопоставлял монолитные приложения и микросервисы. На самом деле чем лучше приложение разделено на части, тем лучше оно централизовано. Приведу сначала пример житейский, если каждый сотрудник автономно выполняет порученную ему работу хорошо и качественно, то сокращается взаимодействие между сотрудниками, уменьшаются расходы времени на контроль и переделывание работы, при этом монолитность иерархических структур упрочняется чем более автономен каждый сотрудник в организации. Что же противопоставить, что же плохо? Плохо - смешивать уровни абстракции, в ноде распространено смешивать все в кучу, я приводил пример тут: habrahabr.ru/post/247543 цитирую:

Прикладной код часто смешан с системным. Дело в том, что нода, и большинство производных фреймворков, слишком низкоуровневые и каждое приложение обязательно содержит часть системного кода, не относящегося к задачам предметной области. Вот и случается, например, что добавление HTTP заголовка становится методом класса Patient и находится в одном файле с заданием роутинга URLов к сему пациенту и с отправкой событий через веб-сокеты. Это чудовищно.

Монолит - это не плохо. Плохо, когда смешаны слои абстракции, если это не понимать, то микросервисы ничего не дадут. Это приводит к высокой связанности кода, когда каждый фрагмент зависит от множества других. Внутри каждого микросервиса можно сделать полное месиво абстракций. Лучше планировать архитектуру слоями, ниже - слои системные, выше - прикладные. Иногда их нужно 2, иногда 3, иногда больше. В каждом модуле, конечно у вас будут как минимум: внешний интерфейс (содержащий внешние вызовы и спецификации форматов данных для обмена), внутренняя логика и внутренние структуры данных. Задача архитектора сделать так, чтобы интерфейс модуля экранировал внутренние структуры данных и внутреннюю логику от зависимостей. При этом, делить приложение на сотни процессов не обязательно, даже внутри одного процесса вы можете связать компоненты по принципу микросервисов, посадив их на шину событий, это будет называться модель акторов.

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!