Часто вижу такие слова как сервисы, микросервисы, контроллеры, репозитории и т.д.
Что есть что и где это объесняется и в каких книгах про это пишут ?
Не претендую на истину в последней инстанции, но расскажу моё понимание.
В программировании, как и вообще везде, со сложностью борятся следуя принципу "разделяй и влавствуй".
Потому, когда мы разрабатываем сложные системы, мы делим их на более мелке подсистемы, мелкие делим ещё и продолжаем деление, пока не получим минимальную задачу, что мы можем решить без дальнейшего деления.
Для примера, можно представить какую то большую систему "Управление предприятием", которая уже делится на подсистемы типа
Каждая из этих подсистем может состоять из своих подсистем и так далее. Если я хочу описать архитектуру, то я обычно перестаю делить подсистемы на моменте, когда подсистема уже представляет собой единое приложение. Под единым приложением я имею ввиду, что оно, как правило, имеет единую кодовую базу для бизнес логики и деплоится на сервер полностью. То есть нельзя зедеплоить только половину приложения и сказать, что оно работает - ты либо его целиком устанавливешь, либо вообще не устанавливаешь. Но, еще раз, это получится логический блок, который я бы уже не стал делить на диаграмме архитектуры системы.
Как пример, "система работы с клиентами" может содержать в себе подсистему "обслуживание заказов от клиентов" в виде "сервиса заказов". Сервис заказов уже не делится на части, потому это конечная. Понимаю, что объяснение у меня чуть путанное, потому, для ясности, я говорю о третьем уровне модели C4 https://c4model.com/
Итак, тут важно понять, что "сервис заказов" - это больше логическое понятие. То есть какой то набор софта, который в совокупности обслуживает заказы. Обычно это просто что то типа .net приложения + БД, но бывает это и приложение + БД, + какие то очереди, триггеры, компоненты облачных сервисов и тд.
Итак, сервис - это логичесое понятие.
Вот есть сложная система. Разбили её на подсистемы, подсистемы на сервисы. В итоге сложная система представляет собой набор взаимосвязанных сервисов. В общем случае это называется SOA или сервис-ориентированная архитектура.
Этот набор надо как то поддерживать и развивать. И вот вопрос: а как так организовать сервисы, чтобы их было удобно развивать, добавлять новые сервисы, удалять старые, чтобы еще система продолжала работать все лучше и лучше? Тогда придумали определенные правила, что то набодобие паттернов для классов, только эти правила для сервисов, но принципы похожие. Например, сервис должнен отвечать за что то одно, у сервиса должна быть своя БД, ну и так далее. И сервис, который отвечает этим требованиям, решили назвать микросервисом.
Типа как есть просто код, а есть "чистый код" (см книгу Роберта Мартина). Также по аналогии, есть просто сервис ориентированная архитектура, а есть микросервисная архитектура. По сути, любая микросервисная архитекрура является также сервис ориентированной, но не наоборот. Подытожу: микросервиная архитекрура - это способ разбиения вашей системы на сервисы, следуюя каким то правилам для микросервисов.
Теперь про сервис. Допустим, сервис представляет собой asp.net приложение. Это приложение в конечном итоге представляет собой композицию классов. Каждый класс имеет своё назначение. Например, класс-репозиторий обычно предоставляет доступ к считыванию/записи каких то данных в какое то хранилище типа базы данных. Чтобы знать больше, читайте книги по паттернам проектирования.
Помимо паттернов проектирования для единичных классов, есть архитектурные паттерны, которые помогают разделить какую то часть приложения на набор взаимосвязанных классов. Тот же паттерн MVC - Model-View-Controller разделяет ваше приложение на 3 части - модель, представление, котонроллер. Модель - это классы для хранения ваших данных, представление - это классы для отображения данных, контроллеры связывают модели и отображения и вызывают нужную бизнес логику. Чтобы знать больше - читайте про архитекрутные паттерны типа MVC, MVP, MVVM, и так далее.
До этого мы шли сверху вниз, теперь, для закрепления, сходим снизу вверх.
Итак, на самом нижнем уровне у нас код, классы.
Классы/код формируют сервис. Сервис - логическое понятие, по сути это что то такое, что рассматривается как единое целое, которое нет смысла делить на более мелкие сервисы. Некоторые сервисы можно считать микросервисами, если они удовлетворяют конкретным критериям. Если все сервисы вашей системы - это микросеркисы, то у вас микросервисная архитектура. Если нет - то просто сервис-ориентированная архтитектура.
Сервисы формируют подсистемы. Подсистема отвечает за какой то класс задач. Типа "бухгалтерия" или "система работы с клиентами".
Подсистемы формируют системы. Система - это уже такая вещь, которая покрывает все ваши нужды в определенной области. Например, в управлении предприятием.
Нет четких градаций типа количества вложенности подсистем. Вы можете всртретить как Система-подсистемы-подистемы-сервисы-код, так и просто система-сервисы-код.
Надеюсь, что я что то смог пояснить, а не ещё больше запутал. =)
За опечетки сорян, если кому не лень - поправьте.