Is saga really an entity, and why it must has an uniqueId?

[netfocus]

After read some posts here, i know that saga is an entity, and it has an uniqueId, and we should persist saga.

The question is why saga should has an uniqueId?

I think saga is just a business flow logic processor, like a state machine. And i agree that saga has status, but it seems that saga not must has an uniqueId.

Take OrderProcessor for example. OrderProcessor is a saga, and OrderProcessorFinder is a router which used to response the domain event or command, in the event handler or command handler method, it will find the correct OrderProcessor (a saga) by OrderId.

Maybe someone will said, for the ExpireRegistrationProcess (see the below code) command, to find the correct saga, we should use the saga Id. But my question is why we cannot also use the OrderId instead? In fact one order should always mapping to only one OrderProcessor, is that right?

So it seems that in no case we must use the saga id to locate the saga. Could anyone explain why we must have an saga Id?

The background why i ask this question is that recently i learned LMAX architecture, it has three key components: input events (like commands in CQRS), business logic processor (aggregate + saga), output events. And the whole business logic processor is working in memory. If we want to rebuild the whole business logic processor, the only way is replay all the input events (it is called event sourcing pattern). And when replaying all the input events, all the aggregates and sagas will be re-constructed and the status will be recovered to the lastest status. That means any saga is always constructed by responsing the aggregate output events. Suppose saga has its own id, and its value will be assigned when saga is instanciated. Like the following code:

public OrderProcessor()

{

    this.Id = GuidUtil.NewSequentialId();

}

As you know, anytime when we create a new OrderProcessor, the Id of this OrderProcessor is different than any others. But the ExpireRegistrationProcess command is persisted in log, and the ProcessId of that command must be not equal with the new one, although their OrderId is same. So in this case if we replaying the command, we can never find the correct OrderProcessor again.

Below is the code of ExpireRegistrationProcess command:

public class ExpireRegistrationProcess : ICommand

{

    public ExpireRegistrationProcess()

    {

        this.Id = Guid.NewGuid();

    }

    public Guid Id { get; set; }

    public Guid ProcessId { get; set; }  //this is the OrderProcessorId

}

So, it seems that in LMAX, both aggregate and saga won't be persisted, all we persist is input events (commands). And if we want to rebuild the business logic processor, we just replay all the input events (commands). In fact, any saga is created after its associated aggregate, like OrderProcessor is created after Order created, so we can always use the OrderId as the saga id. What do you think?

Below is the code snippet of OrderProcessorFinder and OrderProcessor (saga):

public class OrderProcessorFinder :

    IEventHandler<OrderPlaced>,

    IEventHandler<OrderUpdated>,

    IEnvelopedEventHandler<SeatsReserved>,

    IEventHandler<PaymentCompleted>,

    IEventHandler<OrderConfirmed>,

    ICommandHandler<ExpireRegistrationProcess>

 {

 }

public class OrderProcessor

{

    public void Handle(OrderPlaced message) {}

    public void Handle(OrderUpdated message) {}

    public void Handle(Envelope<SeatsReserved> envelope) {}

    public void Handle(PaymentCompleted event) {}

    public void Handle(OrderConfirmed event) {}

    public void Handle(ExpireRegistrationProcess command) {}

}

[Greg Young]

What you are doing is just promoting the orderid to be used as a correlationid. Then making the assumption that only a single thing listens to the conversation.

Also this is not really a saga per se but a process manager that you seem to be discussing (PEI vocabulary).

[netfocus]

Yes, its in fact a process manager. The code i take was from a microsoft event sourcing sample project. http://msdn.microsoft.com/en-us/library/jj554200.aspx

My doubt is is there any difference between saga and process manager?

[Jimmy Bogard]

Yes, there is a difference. See

http://msdn.microsoft.com/en-us/library/jj591569.aspx

For a good description

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nuno Lopes]

Hi.

Interesting article.

The article states that a Process Manager does not contain business logic. Suppose that that an order should be cancelled when the seats cannot be reserved as it happens it is the last show. Would this be handled by the PM? In such case isn't it doing a bit more then message routing?

Cheers,

Nuno

[Nuno Lopes]

It might be a process manager, it can be a good collaboration pattern in a distributes system, but it does make automated business decisions. It seams to be nonsensical to think it can do that without business logic of any kind.

Nuno

On Tue, Feb 19, 2013 at 12:46 AM, Jimmy Bogard <jimmy....@gmail.com> wrote:

[Angel Java Lopez]

Hmm... I guess the SeatReservedm and SeatNotReserved at:
http://msdn.microsoft.com/en-us/library/JJ591569.cd1086a397727a80a919da87626af940(l=en-us).png

could be routed to Order Aggregate, changing the routing in Processor.
Then, this aggregate could decide if it continues sending more message
to complete or not the order.

The only problem, is it has TWO messages (SeatReserved and
SeatNotReserved). It could be "more simple" to have only ONE message
emited by Reservation Aggregate.

Angel "Java" Lopez
@ajlopez

[Alexey Raga]

>>a Process Manager does not contain business logic

>>to be nonsensical to think it can do that without business logic

LOL, this discussion pops up here and there periodically. I think it is a language problem: what go you call "business logic"?

One may say that actual algorithms of calculating a discount is a business logic. Then no, process managers don't contain this kind of business logic.

Others may say that the decision making process is an ultimate example of a business logic. Then yes, process managers "own" this business logic.

Process managers are like army generals, or like your bosses: they don't "do" anything. They command you to do something, review the results and command something else based on these results. If some activity is involved in this decision making process (like counting how many soldiers are still alive) then they wouldn't do it themselves, they would delegate it to someone else, have the result back and then make a decision.

Cheers,

Alexey.

[Nuno Lopes]

I call business logic what the business thinks its business logic, not what a developer thinks it is. Anything that is in the business requirements doc is business logic, that includes for instance statements like "all reservations that are not met go to a waiting list". Developers tend to complicate things too much.

IMHO the reason why some might state that X is not business logic its because they want to put in some concept outside of the domain model so avoiding the conceptual issue of not being neither an Aggreagte or a Domain Event.

So from a DDD perspective, is a Process Manager part of the domain model or not?

Cheers,

Nuno

[Angel Java Lopez]

Hi people!

My interpretation, is that the author of the article wants to say:

- Process Manager is agnostic, independent of what business you are
managing. In the same way that a File System is independent of what
you are saving in files
- Generally, a Process Manager could be written in such way that the
routing of messages can be handle by configuration
- Routing is based on message content. Something like: "given message
M, predicate P, if P(M), then transform M to N, routes N to target A"

Or maybe, I'm putting a lot of my own preconceptions ;-)

Maybe, the discussion is: routing logic is business logic?

Angel "Java" Lopez
@ajlopez

[Alexey Raga]

>> Process Manager is agnostic, independent of what business you are managing 

I disagree.

Process managers are not only agnostic to the business, they represent business workflows. They model specific business processes that make sense for a specific business.

When you say that they just route messages you think technically.

Process managers are places when decisions are made. They describe how the specific business reacts on things that happen inside and outside.

    When OrderAccepted

         And PaymentReceived does not happen for next 10 days

    Then CancelOrder

This describes how business operates. This is what domain experts are talking about when you ask them to explain the "business logic" behind payments and cancellations. Even if technically it looks like just routing. If my business works like that, your can work differently and have different processes and business rules. Each business is unique.

To me this is the real business logic, not how we go to the database and which flags we set on which DTOs and which APIs we use (what us developers usually call "business logic"). Business doesn't care about these flags and APIs.

Process managers describe how the specific business works in ubiquitous language which by definition cannot be "agnostic and independent from business that managed".

[Kijana Woodard]

+1 Alexey
I like your bosses analogy. It is a process 'manager' after all. :-)

@Nuno - I've always wanted to work at a place that had requirements documents. At this point I think I'd miss doing analysis. ;-)

[Nuno Lopes]

I've worked in many environments. Some have formal requirements docs, others use a more informal schemes of documenting requirements. For instance, using email as a form of documentation. 

Unless you have infinit funds working on an open project my advice to write down those requirements using a scheme of preference and have the interested partities commit to those.

[Nuno Lopes]

It is a Behavioural Pattern regarding events and commands. 

The closest thing to it is the Mediator Pattern, but it just uses Commands.