Что такое саги и почему они используют архитектуры, управляемые событиями?

Question

я наткнулся на следующий код:

public class ShippingSaga : Saga<ShippingSagaData>, 
     ISagaStartedBy<OrderAccepted>, 
     ISagaStartedBy<CustomerBilledForOrder> 
    { 
     public void Handle(CustomerBilledForOrder message) 
     { 
      this.Data.CustomerHasBeenBilled = true; 
      this.Data.CustomerId = message.CustomerId; 
      this.Data.OrderId = message.OrderId; 

      this.CompleteIfPossible(); 

     } 

     public void Handle(OrderAccepted message) 
     { 
      this.Data.ProductIdsInOrder = message.ProductIdsInOrder; 
      this.Data.CustomerId = message.CustomerId; 
      this.Data.OrderId = message.OrderId; 

      this.CompleteIfPossible(); 
     } 

     private void CompleteIfPossible() 
     { 
      if (this.Data.ProductIdsInOrder != null && this.Data.CustomerHasBeenBilled) 
      { 
       this.Bus.Send<ShipOrderToCustomer>(
        (m => 
        { 
         m.CustomerId = this.Data.CustomerId; 
         m.OrderId = this.Data.OrderId; 
         m.ProductIdsInOrder = this.Data.ProductIdsInOrder; 
        } 
        )); 

       this.MarkAsComplete(); 
      } 
     } 
} 

По внешнему виду вещей в приведенном выше коде саг, кажется, какой-то более высокий уровень координатор/контроллер событий. Это правда? Если да, используются ли они только в управляемых событиями архитектурах? И наконец, являются ли саги части ИНФРАСТРУКТУРЫ?

первый запрос похоже ответ. но где они действительно относятся к ответственности, то есть к инфраструктуре? Домен ? , применимы ли они только к EDA?

Answer 1

Предупреждение: есть некоторые путаницы, особенно около nservicebus по определению «Сага»; Смотри ниже.

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

Они аналогичны человеку, который смотрит на представление и отправляет команды модели записи. См. Статью Рината Абдуллина Evolving Business Processes для получения дополнительной информации о этой точке зрения.

Они служат описанием бизнес-процесса, то есть они определяют дополнительные решения (команды), которые должны выполняться агрегатами. В реализации они очень много состояний машин - заданное событие X и событие Y, диспетчер процессов находится в состоянии (XY), и команды, которые он будет рекомендовать, исправлены.

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

public class ShippingSaga : Saga, 
    ISagaStartedBy<OrderAccepted>, 
    ISagaStartedBy<CustomerBilledForOrder> 
{ 
    public void Handle(CustomerBilledForOrder message) 
    { 
     this.process.apply(message); 
     this.CompleteIfPossible(); 
    } 

    public void Handle(OrderAccepted message) 
    { 
     this.process.apply(message); 
     this.CompleteIfPossible(); 
    } 

    private void CompleteIfPossible() 
    { 
     this.process.pendingCommands().each (m=> 
      this.Bus.Send(m); 
     } 
    } 
} 

Или то же самое - если вы предпочитаете думать о неизменных структурах данных

public class ShippingSaga : Saga, 
    ISagaStartedBy<OrderAccepted>, 
    ISagaStartedBy<CustomerBilledForOrder> 
{ 
    public void Handle(CustomerBilledForOrder message) 
    { 
     this.process = this.process.apply(message); 
     this.CompleteIfPossible(); 
    } 

    public void Handle(OrderAccepted message) 
    { 
     this.process = this.process.apply(message); 
     this.CompleteIfPossible(); 
    } 

    private void CompleteIfPossible() 
    { 
     this.process.pendingCommands().each (m=> 
      this.Bus.Send(m); 
     } 
    } 
} 

Так судоходная процесс определяется в терминах области бизнеса, и «Saga» интерфейсы NServiceBus что бит бизнес-домена с инфраструктурой шины. Разве не разделение проблем прекрасное.

я использую «Saga» в кавычках, потому что - NService bus sagas не особенно хорошо подходят для prior use of the term

Термин сага обычно используется при обсуждении CQRS сослаться на часть кода, координирует и маршрутизирует сообщения между ограниченными контекстами и агрегатами. Однако для целей этого руководства мы предпочитаем использовать термин диспетчер процессов для обозначения этого типа артефакта кода. Для этого есть две причины:

• Существует известное, ранее существовавшее определение термина сага, имеющее другое значение из понятия, общепринятого в отношении CQRS.
• Термин диспетчер процессов - лучшее описание роли, выполняемой этим типом артефакта кода.