Следующие главы более подробно описывают то, как правильно выделить микросервисы. Информации много, и чтобы корректно её понять в полном контексте, крайне желательно прочитать и посмотреть на все таблицы своими глазами. Я лишь приведу очень сокращенный конспект.
Как я уже писал выше, автор предлагает делать это в 3 этапа:
* Определить системные операции: определяем пользовательские истории и связанные с ними сценарии использования.
Сначала определяется доменная модель: перечисление основных сущностей приложения, завязанных на требования к приложению. Например, для приложения-доставки это могут быть: Order, Restaurant, Delivery, Courier и другие.
Затем определяются операции, связанные с этими сервисами. Например, клиент может создать заказ - операция createOrder. Ресторан может взять заказ на обработку - операция acceptOrder. Курьер может доставить заказ - операция deliveryDelivered. Аналогично с операциями опередляются запросы, которые приложение будет обрабатывать: запрос на доступные рестораны - findAvaliableRestaurants, и так далее.
На этом этапе, вероятно, не получиться учесть все операции и запросы, но чем больше операций и запросов получиться выделить и спроектировать - тем проще будет их сгруппировать и тем больше будет вероятность того, что сервисы будут выделены верно.
* Второй этап - разбиение на сервисы, исходя из запросов, описанных ранее. Вероятно, доменная модель сможет показать сервисы без каких-либо дополнительных действий. Но, автор приводит и несколько стратегий, которые можно применить, если явно выделить сервисы не получается.
Первая - разбиение на сервисы по бизнес-возможностям. Бизнес-возможности определяют то, чем занимается организация и что она предлагает своим клиентам. Например, что предлагает клиентам приложение-доставка?
1. Управление поставщиками - курьерами и информацией о ресторанах.
2. Управление клиентами
3. Прием и выполнение заказов: создание заказов, управление заказами, логистика, управление доступностью курьеров, управление доставкой
4. Бухучёт: отчётность по клиентам, по курьерам, по доставкам и так далее.
5. ...

Иногда сервисы создаются для бизнес-возможностей верхнего уровня, а иногда отдельный сервис может быть создан для подвозможности. Например:
Управление курьерами - сервис Courier (сервис для подвозможности)
Управление информацией о ресторанах - сервис Restaurant (подвозможность)
Управление клиентами - сервис Consumer
Управление заказами для клиента, создающего заказ - сервис Order (подвозможность)
Управление заказами в ресторане - сервис Kitchen (подвозможность)
Управление доступностью курьеров и доставка - сервис Delivery (подвозможности)
Бухучёт - сервис Accounting
И так далее.

Решение, для каких возможностей создавать отдельный сервис - субъективно.

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

Смотря на примеры сервисов, приведённые автором, явно вспоминается принцип единственной ответственности, и он тут на самом деле фигурирует. Мы выделяем команды и запросы, а потом группируем их и формируем на их основе отдельный сервис, который будет иметь, очень абстрактно, одну причину для изменений.
Ещё один принцип, применяемый при декомпозиции - принцип согласованного изменения: изменение пакета должно затрагивать все его классы (Роберт Мартин). Или, другими словами: если два класса изменяются вместе по одной и той же причине - они должны входить в один пакет.

Какие трудности могут возникнуть при разбиении приложения на сервисы? Помимо пары сотен других, автор приводит следующие: