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

Я думаю, что есть разный опыт использования микросервисов. Кто-то больше видит в них часть хранилища, кто-то обработчика сообщений. Мой опыт - обработчики сообщений

Т.е. скорее реализацию модели акторов?

Что касается границ микросервсов, а значит и их размера, доминирует мнение, на мой взгляд, что границы микросервисов - ограниченный контекст

Я не достаточно акцентировал в теме MonolithFirst рекомендацию выделять  микросервисы по мере необходимости. Т.е. мы их отделяем от монолита в ходе его жизненного цикла. Какого размера компонент удастся выделить - заранее не понятно

Скорее - системы акторов, если речь идёт о акторной модели

Да

Мне почему-то казалось, что (микро)сервисы - понятие пассивное, т.е. вызывается извне и возвращает ответ. Акторы же - активные. И в этом эти модели различны.
Это было заблуждение?

Ну вот если бы были описаны референсные модели предметных областей :-( А когда их формулируют заказичики все становится зыбко. Сегодня один отдел занимается той или иной функцией, завтра - другой, потом оба этих отдела реформируют и подчиняют третьему, у которого свой взгляд на основные сущности предметной области

Microservices follow only one "measure" - the Single Responsibility Principle (SRP). One function per microservice. And, a microservice with "wide" responsibility may be assembled from microservices with "narrow" responsibilities.

То есть тут "микро" скорее имеет не абсолютное, а относительное значение, относительно остальной части системы?

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

Да, вот это согласуется с моим представлением. "Узкосервис" гораздо более понятен, чем микросервис 😊

Есть и такое мнение, но это уже наносервис )

Все зависит от "размера" ответственности - практически все бизнес-процессы это микросервисы собранные из дрегих микросервисов. Тут не "нано" и не "узко", так как, это готовые приложения.

Микросервисы особенно полезны для выравнивания скорости развития бизнеса и ИТ, поэтому и границы - ограниченный контекст, то есть некий относительно независимый поддомен

Если информационная система - набор независимых, одновременно исполняющихся процессов, с общими сценариями хореографии, какие там внтури вообще могут быть пассивные элементы (ну кроме файлов :). Думаю, что мы неправильно моделируем информационные системы, например, посредством use cases. Их придумали во времена однозадачных приложений,  синхронно взаимодействующих с пользователем. Я уже делился вот этой ссылкой https://less.works/less/principles/systems-thinking.html из Large-Scale SCRUM Есть много и других разговоров на эту тему

Хорошее замечание. ДУмаю оно справедливо

Вот мне всегда казалось, что это именно модель акторов. В чистом виде.

+1