Микросервисы - один домен и несколько функций, которые масштабируются с разной скоростью - PullRequest
1 голос
/ 06 марта 2020

Я новичок в DDD и в микросервисах, и мне хотелось бы узнать, как подойти к ситуации.

Допустим, у меня есть система с заказами. Каждый заказ может иметь несколько предметов. Поэтому я думаю, что это будет определенный c домен.

Затем, когда я больше смотрю на заказы, я обнаруживаю, что мы предложим следующее:

  • каждый элемент в заказе собирается с разных складов и статус каждого элемента (например, подготовлено, перемещается в пункт сбора), а также etas отображается для клиентов для их заказа.
  • после того, как все элементы собраны, мы предоставляем статус, eta и gps местоположение заказа с регулярными обновлениями.

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

То, что ощущалось как домен Заказа, теперь, похоже, имеет компоненты / функции, которые масштабируются с другой частотой. Например, мне нужно только 10 экземпляров API заказа, но 50 экземпляров обработчика уведомлений о заказе, также мы принимаем заказы 24/7, но мы собираем товары и доставляем заказы только в определенные дни и часы. Эти двое разделяют большую часть данных (заказы и позиции в заказе) и должны постоянно сообщаться вместе.

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

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

Как бы вы справились с этим при использовании DDD и микросервисов? Есть известная проблема / шаблон, о котором я мог бы прочитать больше?

Спасибо!

1 Ответ

1 голос
/ 06 марта 2020

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

Например, контекст вашего заказа может содержать описание заказа, а в контексте доставки вы можете может понадобиться это описание для почтовой этикетки. Вы сохраните то же описание в 2 местах, и это нормально. В будущем вы можете решить добавить «Идентификатор доставки» к почтовому ярлыку, и, поскольку у вас есть отдельные контексты, это добавление будет тривиальным и никак не повлияет на ваш контекст заказа.

Я не понял что вы имели в виду под «10 экземплярами API заказа или 50 обработчиками уведомлений». Поэтому я не могу решить эту проблему.

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

Контекст заказа не должен иметь дело со сбором товаров, доставкой или местоположениями. Или их события. Вам нужен Delivery Context и, возможно, Gathering Context тоже.

Таким образом, можно сохранять одни и те же данные в разных контекстах, если это имеет смысл в вездесущем языке. Кроме того, разработайте свой контекст в соответствии с основными функциями вашей системы (заказ, сбор и доставка).

...