О, мой друг, вы просто усложняете весь сценарий, но это не ваша вина, такие компании, как MSFT, Oracle и другие крупные поставщики программного обеспечения корпоративного класса, любят создавать общую картину чего-то, что намного проще, и они делают это для Причина: вертикальное масштабирование сервисов означает больше лицензий.
Вы можете использовать другой подход и на мгновение забыть обо всех этих громких словах, EJB, JPA... и, как однажды сказал один умный человек, разделить большую проблему на более мелкие части, чтобы вместо большой проблемы у вас было несколько небольшие проблемы, с которыми теоретически должно быть легче справиться.
Итак, у вас есть несколько сервисов в вашей системе: люди, платежная система, заказы, продукты, ERP... на мгновение давайте подумаем, что эти границы правильны с точки зрения бизнес-объектов. Представьте, что эти сервисы — это разные физические отделы вашей компании, а это значит, что они заботятся только о принадлежащих им данных и ни о чем другом.
Тогда вы могли бы сказать, что отдел платежей имеет свою собственную базу данных, то же самое относится и к заказам, конечно, им по-прежнему необходимо взаимодействовать друг с другом, как это делают все отделы, и это можно упростить с помощью открытого суррогатного ключа, сгенерированного системой. Все это означает, что каждая служба поддерживает ссылочную целостность всех своих внутренних сущностей, используя внутренние ключи, но если записи необходимо сделать доступными для других служб, вы можете, например, использовать ключ Guid, например:
Службе платежей требуется идентификатор заказа и идентификатор клиента, но эти объекты принадлежат их собственным службам, поэтому вместо совместного использования закрытого ключа (первичного ключа) каждой записи каждая запись будет иметь первичный ключ и суррогатный внешний ключ. службы будут использовать для обмена между ними. Дело в том, что вы должны стремиться создавать слабосвязанные сервисы, каждый со своей «маленькой» базой данных. Каждая служба также должна иметь каждый собственный API, который должен использоваться не только внешним интерфейсом, но и другими службами. Еще одна вещь, которую вам следует избегать, — это использование DTC или другого поставщика управления транзакциями в качестве гаранта транзакций на уровне службы, это то, что можно легко заархивировать, просто используя другой подход к архитектуре.
В любом случае, прочитайте, если вы еще не знакомы с DDD, это даст вам другой обзор того, как создавать программное обеспечение корпоративного класса и, кстати, EJB, убегать от них.
ОБНОВЛЕНИЕ:
Вы можете использовать что-то вроде SOA событий, но давайте не будем усложнять. Зарегистрированный клиент приходит на ваш сайт, чтобы сделать заказ. Ответственная за это служба — Заказы. Список внешних идентификаторов продуктов передается в службу заказов, которая затем регистрирует заказ, в этот момент заказ находится в состоянии «ожидает оплаты», и эта служба возвращает общедоступный идентификатор заказа Guid. Для выполнения заказа покупателю необходимо оплатить товар. Детали платежа отправляются в платежную службу, которая пытается обработать платеж, но для этого ему нужны детали заказа, потому что единственное, что отправил интерфейс, — это идентификатор заказа, и для этого он использует GetOrderDetails(Guid orderId) из API заказа. После завершения платежа служба платежей вызывает еще один метод API заказа PaymentWasCompletedForOrder(Guid orderID). Дайте мне знать, если есть что-то, что вы не получаете.
person
MeTitus
schedule
01.04.2013
