День 1085. #ЗаметкиНаПолях Использовать ли Одинаковые Идентификаторы в Разных Микросервисах Существует распространённый и довольно интересный вопрос о том, как управлять идентификаторами в архитектуре микросервисов. Этот вопрос лучше всего описать на примере, поэтому, допустим, у нас есть два ограниченных контекста, Sales и Support, которые работают в своих соответствующих микросервисах (см. картинку ниже). В обоих этих микросервисах есть одна и та же сущность клиента (Customer). Предположим также, что сервис продаж является вышестоящим по отношению к сервису поддержки. То есть, когда клиент создаётся в продажах, он передаётся в поддержку, которая создаёт собственное представление этого клиента. Отсюда вопрос: «Должен ли сервис поддержки использовать тот же ID, что и сервис продаж, или нужно назначать собственный ID своей версии клиента?» Если вы используете UUID(GUID), вы можете легко назначить раздельные ID клиента в обоих сервисах, и идентификаторы в двух ограниченных контекстах не будут пересекаться. Но хорошо ли это? Нет. Используйте один и тот же идентификатор во всей вашей системе, если этот идентификатор создаётся одним из ваших микросервисов. ID — это одно из свойств, представляющих клиента. Идентификатор контролируется микросервисом, который создаёт экземпляры клиента. В нашем примере это сервис продаж. Новые клиенты создаются, когда ваша компания что-то им продаёт. Поэтому Sales — главный микросервис для идентификации всех клиентов. Только сервис Sales может назначать ID. Нижестоящие сервисы должны реплицировать его в свои базы данных, аналогично тому, как они реплицируют свойства Name или Email. Когда вы смотрите на идентификаторы с этой точки зрения, становится ясно, что не имеет смысла назначать раздельные идентификаторы клиентов в нижестоящих микросервисах, так же как не имеет смысла назначать разные имена или адреса электронной почты. Пока только один микросервис контролирует время существования определённого объекта (то есть может создавать и удалять его), у вас всегда будет только один идентификатор в вашей системе, даже если эта система состоит из нескольких микросервисов. А что, если идентификатор поступает из внешней системы? Предположим, клиенты могут зарегистрироваться в вашей системе через свои социальные профили, такие как Facebook. В этом случае Facebook предоставит вашей системе собственный идентификатор. Стоит ли использовать этот идентификатор Facebook как есть? Нет, вам нужно создать собственный идентификатор клиента и сохранить идентификатор Facebook как отдельное (необязательное) поле. Разница здесь в том, что у вас нет контроля над идентификаторами, которые предоставляет вам Facebook. Facebook потенциально может изменить эти идентификаторы и испортить вашу систему. Контракт между вашими микросервисами намного прочнее, чем между вашей системой и Facebook. Вы можете (и должны) поддерживать обратную совместимость между микросервисами в вашей системе. Нет никакой гарантии такой совместимости между вашей системой и Facebook. Источник: https://enterprisecraftsmanship.com/ Автор оригинала: Владимир Хориков