Сервис-ориентированная архитектура: внешний ключ для разных баз данных

Question

Мы внедряем сервис-ориентированную архитектуру (SOA). У нас есть разные сервисные базы данных для каждого: Управление клиентами, Заказы, Доставка, Возврат. Каковы стратегии для поддержания отношений внешнего ключа между таблицами в разных базах данных (поскольку внешние ключи нескольких баз данных не допускаются в SQL Server)? Должны ли внешние ключи заменяться правилами бизнес-API?

Это не микросервисы; где информация базы данных реплицируется на каждой арене, но SOA. Мы не хотели помещать все в 1 базу данных, так как разные часы обслуживания резервного копирования не хотели, чтобы запрос взаимоблокировки / разгона сбивал все службы. Сервис-ориентированная архитектура не диктует, нужна ли нам одна база данных или несколько.

Answer 1

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

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

Имеет смысл?