Обучение DDD и CQRS

Question

Я новичок в DDD и CQRS и планирую создать простое приложение, чтобы немного улучшить свои навыки.Я планирую сделать простое приложение Taxi Corp.

Требования:

1. Клиент заказывает такси.
2. Клиент может заказать только один заказ.время.
3. Водитель выбирает заказ.
4. Водитель может иметь только один заказ за один раз.
5. Водитель едет к клиенту.
6. Клиент заходит в кабину.
7. Курс начинается.
8. Курс заканчивается.
9. Клиент куплен, а водитель оплачивается

И т. Д.

Я вижу, что может быть три совокупности: клиент, заказ и водитель.Я хочу разделить их на отдельные микросервисы.Как вы думаете, это хорошая идея, или я должен начать с одного микросервиса?

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

Процесс создания заказа

Answer 1

Я вижу, что может быть три агрегата: Клиент, Заказ и Драйвер.Я хочу разделить их на отдельные микросервисы.Как вы думаете, это хорошая идея, или я должен начать с одного микросервиса?

Все они принадлежат к одному ограниченному контексту.Ограниченный контекст прекрасно переносится на микросервисы (см. Видео Эрика Эванса: https://www.infoq.com/news/2015/06/dddx-microservices-boundaries). Но не начинайте с проектирования микросервиса, вы делаете это в неправильном порядке. Сначала спроектируйте свой ограниченный контекст, а затем, если это имеет смысл, создайтемикросервис вокруг гексагональной архитектуры.

После создания заказа мне нужно назначить его клиенту. Так как во время одного запроса можно обновить / создать только один агрегат, мне интересно, как это сделать правильно.

Это прекрасный пример того, почему вам нужно делать все это в одном и том же процессе.

Но если вы хотите использовать несколько микро сервисов, подумайте о возможной последовательности (https://en.wikipedia.org/wiki/Eventual_consistency) и создать управляемую сообщениями архитектуру между вашими сервисами. На мой взгляд, это может быть слишком много работы, но для целей обучения может быть хорошей идеей.

Answer 2

Кто-то сказал: «Если у вас больше микросервисов, чем у клиентов, вы делаете это неправильно».

И если вы действительно следуете подходу CQRS / ES, полученную систему гораздо проще разделить, чем традиционные монолиты ORM..

Итак, сначала сфокусируйтесь на домене и начните с монолита.

Answer 3

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

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

• рассмотрим микросервис менеджера заказов для назначения клиента и водителя в поездку по их идентификаторам.база данных заказов может включать в себя таблицу командировок с двумя ключами идентификатора для идентификатора драйвера и идентификатора клиента и некоторые столбцы для различных состояний.После завершения каждой поездки вы можете удалить ее из таблицы поездок и вставить в архивную таблицу.кроме того, вы можете оставить его там и ежедневно разбивать вашу таблицу, чтобы поддерживать высокую производительность вашей базы данных.

• рассмотрим бухгалтерский микросервис для ведения платежей и транзакций.Это нормально, если вы решите использовать базы данных NoSql для других микросервисов, но используйте базу данных SQL для своих транзакций.

• вам может понадобиться другой микросервис для отчетов и панелей мониторинга.зеркально отразите другие базы данных в новом для отчетов.

• вам также необходим шлюз API для маршрутизации запросов к микро-сервисам или для аутентификации

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

Answer 4

Как вы думаете, это хорошая идея, или я должен начать с одного микросервиса?

Я отсылаю вас к мудрости Джона Галла

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

Вместо того, чтобы беспокоиться о микросервисах, обратите внимание на сообщения .