Я прочитал этот отличный учебник (http://blogs.planbsoftware.co.nz/?p=247) о NserviceBus Sagas, но все же я не понимаю, в чем преимущество этой модели (саги), используя транзакции базы данных или бизнес-уровня?NserviceBus Sagas Utility
Основным преимуществом модели саги является то, что она позволяет брать логику и данные, которые в противном случае были бы распределены по всей системе (и различным заданиям), и вытащить все это в один класс, лучше следовать за одним принцип ответственности. После этого вы получите все другие преимущества, связанные с хорошими практиками программного обеспечения - лучшая тестируемость, ремонтопригодность и т. Д.
Чтобы показать вам реальную пользу модели Saga, я покажу вам два примера.
Представьте, что у вас есть ориентированная на обслуживание архитектура с сотнями распределенных хостов. Клиент делает заказ, который запускает одну или несколько саг. У каждой саги есть своя бизнес-логика. Обработчик для каждой заданной саги можно разделить между разными хостами, и вам не нужно проверять состояние заказа на каждое сообщение, NServiceBus неявно проверяет состояние саги, сопоставляя его с идентификатором заказа или другими атрибутами, и если он все еще открыт, вы получите его ваш контекст данных.
Вы также можете использовать эту модель в качестве шаблона без использования NServiceBus. Представьте, что вы разрабатываете видеоигру и хотите отслеживать некоторые пользовательские комбо. Каждый раз, когда игрок нажимает на вас, вы открываете сагу и добавляете бонусные очки, управляя другим быстрым входом. Как только игрок задерживается в течение некоторого времени между входами и сагой, закрывает себя, экономя общий балл для комбо.
В чем преимущества Saga?
1) Ваша бизнес-логика инкапсулирована в одном месте - сага.
2) Вы можете легко его расширить, добавив дополнительную сагу или удалив их. Вы также можете перенести их на другие обработчики или хосты.
3) Вам не нужно знать, что данные в базе данных требуются в случае миграции, вам просто нужно перенести саги, которые содержат всю необходимую информацию
Большого спасибо Уди. Можете ли вы указать мне простой фиктивный пример, который реализует что-то в обоих направлениях, чтобы я мог понять разницу? Я согласен с тем, что данные состояния будут распространяться по всей системе, но, возможно, мой экзистенциальный вопрос: если эти данные составляют часть бизнес-процесса (и нам может потребоваться запросить данные состояния для отчетов, чтобы клиент знал текущий статус , и т. д.) не имеет смысла хранить данные состояния вместе с бизнес-данными? Еще раз спасибо. – Miguel
Я расскажу следующее о списке вещей. Но серьезно, вы можете напрямую запросить данные саги - он сохраняется в обычной БД. –
Я думаю, что вижу ... Итак, процесс с использованием SagaData действует как координатор распределенной транзакции с доступом к состоянию в нескольких системах, участвующих в транзакции, верно? –