Микросервисная архитектура - тоже архитектурный стиль. Реализация, как правило, представима в виде набора компонентов. Компоненты предствлены сервисами, а в качестве коннекторов - коммуникационные протоколы (например, AMQP вместе с rabbitmq).
Каждый сервис имеет собственную архитектуру, как правило - шестигранную (читай выше).
Каждый сервис можно выделить из какой-либо бизнес-возможности. Например для приложения-доставки, работающего с ресторанами, курьерами и пользователями, можно выделить следующие сервисы (на самом деле потенциально сервисов может быть гораздо больше):
* Сервис ресторанов - светит наружу API, с помощью которого клиент может посмотреть меню и сделать заказ;
* Сервис доставок - светит наружу API, с помощью которого курьер видит, какой заказ и куда ему доставлять.
* Сервис заказов - сервис, обрабатывающий заказы, получая их от ресторана и передающий их в сервис доставки.
* Сервис уведомлений - сервис, с помощью которого другие сервисы могут отправлять клиентам и курьерам информацию о готовности заказов.

Связь между сервисами реализуется с помощью механизма межпроцессорного взаимодействия, например REST API или асинхронного обмена сообщениями.
API состоит из команд (например, обновить заказ), запросов (получить данные по заказу) и событий (заказ создан), которые могут потреблять внешние клиенты.
API сервиса инкапсулирует его внутреннюю реализацию. В отличие от монолита, этот подход не позволяет разработчику писать код, минующий API. Благодаря этому обеспечивается модульность приложения.
Ключевое здесь - слабая связанность сервисов, т.е. каждый сервис ограничен в том, как он может общаться с другими сервисами.
Каждый микросервис обладает собственной архитектурой и иногда разным стеком технологий. Но, как правило, все сервисы имеют шестигранную архитектуру: бизнес-логика вызывается адаптером операций, а события, которые она генерирует, публикуется адаптером событий наружу.

Слабо-связанные сервисы обязательно должны взаимодействовать только через API, и исключать коммуникацию через базу данных.


Теперь коротко об интересном и холиварном: как выделить микросервисы?
Зачем нам вообще приложение и какой его основной функционал? Обрабатывать запросы. Поэтому первый шаг - формируем ключевые запросы, описывая, что мы хотим от приложения и что оно должно сделать в ответ. Например, мы хотим, чтобы клиент смог разместить заказ. А ещё хотим, чтобы ресторан мог этот заказ принять. Наши хотелки - это требования, выраженные в виде пользовательских историй. Когда мы сформировали все требования, из них мы можем выделить внешние запросы, которые будут отправляться приложению. В нашем случае это createOrder, для создания заказа от пользователя и acceptOrder, для приёма заказа рестораном.
Когда все запросы описаны, переходим ко второму шагу - разбиваем на сервисы исходя из запросов. Каждый запрос можно отнести к тому или иному домену: например, запрос createOrder можно отнести к абстрактному домену "Order", запрос acceptOrder можно отнести к доменам "Order" и "Restaurant".
Разбив все запросы на домены, мы сможем выделить, например, сервисы Order, Restaurant, Kitchen, Delivery и так далее.
Третим шагом мы назначаем всем сервисам те операции, которые были выделены на первом шаге. Тут уже будет приблизительно понятно, как сервисы будут взаимодействовать между собой и какой примерный API у них будет.