What is a Process Manager?

[Werner Clausen]

Hi,

 

The CQRS Journey here: http://msdn.microsoft.com/en-us/library/jj591569, says that a Process Manager do not perform any business logic, and it should only work within a single bounded context. Yet the example on the same page shows:

 

1.  Process Manager routing between Order and Payment, but that is two different contexts right?
2.  Process Manager sending an "AddToWaitList" command as a reaction to the "SeatsNotReserved" event, but that is business logic right?.

 

And while we're at it: Is there a clear separation between a Process Manager and a Saga? 

 

--
Werner

[Karl Nilsson]

Hi,

1. There could be another 'edge' component in between that interacts with any other bounded contents (such as Payment) and provides a messaging translation and forwarding layer. Not clear from the article though.

2. Not convinced the Process Manager should be sending a command here. May be better if the 'SeatsNotReserved' event got forwarded to the WaitList aggregate as an event, not a command. Then the aggregate can decide itself how to handle that event. 

Cheers

Karl

--
Karl Nilsson

twitter: @kjnilsson

blog: coderkarl.wordpress.com

[Kijana Woodard]

In my view, the only purpose of a  process manager is business logic - reacting to and issuing events and commands based on business rules. I would word it that process managers shouldn't do any 'work'.

Its tough to say there's no business logic in a process manager but yet it knows that when an order is accepted, a, b, and c need to occur.

[Werner Clausen]

Thanks - I needed to hear that. My thoughts exactly; I was starting to think that I misunderstood the entire concept of business logic :)

 

--
Werner 

[kell.s...@gmail.com]

Yes there's a pretty large difference between a Process Manager and a Saga. 

Here's my post where I try to explain it:

http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

What I'm seeing as examples of Sagas sometimes are actually almost like wanna-be Actors by communicating through messaging and persisting state (emphasis on wanna-be). 

If you compare that to what I consider a possible Saga implementation here you'll see that it has a very different implementation for a very different purpose:

http://vasters.com/clemensv/2012/09/01/Sagas.aspx

Thanks!

Kelly

[Kasey Speakman]

Thank you for clarifying that. I looked at the Saga paper a few times, but my eyes glazed over before I got clarity.

So it looks to me like a Saga is just a series of transactions across separate systems which executes undo actions against each system in case of failure.

Whereas a Process Manager potentially has more behavioral capability. It can remember state and provide more compensating actions than just undo. (e.g. OrderCanceled + OrderShipped => AssessRestockingFee)

If I understand that correctly, then it's too bad that the term Saga was commandeered for the first concept. Since the term's definition seems more apt for the second concept. Probably for this reason and the word Saga being a lot cooler-sounding and shorter to type, people are using it when Process Manager would be technically more accurate.

[Alexey Raga]

Depends on what you call a business logic I believe.

To me Process Managers are there to make decisions on what to do next. They do not "do" anything else.

"When SeatsNotReserved happen Then AddToWaitList" - that's what it does: manages a process. To me it IS a business logic.

A Process Manager definitely belongs to a context, it can just happen that it has its own context :)

So it is totally fine for a Process Managers to listen to the events from different contexts and issues commands to different contexts. That's again what it makes them Process Managers: they are modeling business processes.

Cheers,

Alexey.

[Nuno Lopes]

What if compensation is part of the business process?

[Jimmy Bogard]

That's right - just keep in mind that "NServiceBus Saga" != "Saga pattern as defined in a paper from 1987". When I talk to devs these days, I refer to what NServiceBus defines as the "NServiceBus Saga" so folks in the know don't get confused.

[elbandit]

Hi,

I don't understand why Payments and Orders are two different bounded contexts as there seems to be no ambiguity in the UL that is used within each of them. As far as I remember a bounded contexts boundaries are based on language. Aren't Payments and Orders simply modules (I think Udi calls these Business Components) of a Sales bounded context? Which would mean that the process manager is acting within the sales bounded context and all is good with the world. Also I understand that the process manager acts as the application level so it is valid to send commands as it is the client of the domain layer.

Scott

[Greg Young]

I would say yes they sound like modules or dare I say services in a soa sense

--
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.
 
 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Julian Dominguez]

Scott, in part they could be taken as just different modules (or services), especially since the current implementation of the Payments BC is very simple as everything is mocked out. Our thinking was that this Payments BC would be owned by a different team altogether, and would not be coupled to the Orders BC with respect to data storage, nor full referential integrity and consistency between the two. So we would expect the Payments team to use their own UL if they want to. From my understanding, Evans suggests that the different teams alone is good reason to split a BC, and even more if they have their on boundaries in terms of data store they use.

In fact, even in this very simple version they do not share a UL (but they are not ambiguous as you mentioned, because of the fact that they do not overlap). If you look at the events and commands in the Payments BC, there is not a single mention of this being a part of a conference management system, where as the Orders BC is an ordering system coupled to the conference domain itself. You could reuse the Payments BC in different systems (assuming it was not mocked out), but not necessarily the other BCs we have.

What do you think?

Julian

[Scott Millett]

Hi Julian,

I agree with the points you raised about the Payments BC and agree if created by a different team then it should be a separate BC. However you mentioned... "..where as the Orders BC is an ordering system coupled to the conference domain itself." Do you mean the ConferenceManagement and the Registration BCs? I would consider these within the same BC (based on same team and same UL) correct? However I notice in the MSDN doc that accompanies the solution it says this about BCs:

"You can also view a bounded context as an autonomous business component defining clear consistency boundaries: one bounded context typically communicates with another bounded context by raising events."

So even though a single team could be working on ConferenceManagement and Registration parts, using the same UL they would create separate BCs in order to aid deployment, isolate data and protect the integrity of the domain model in the Registration area?

I often see that in a single BC only one domain logic implementation pattern is used. If you look at ConferenceManagement it has no logic and is CRUD whereas the Registration part is a full domain model. So I am thinking that a Bounded context should be used to isolate based on :

1. A linguistic boundary
2. A team boundary
3. A specific Domain Model (in this case the model in registrations from the CRUD in ConferenceManagement)

Does that make sense?
Scott

On Monday, 29 July 2013 21:59:10 UTC+1, Julian Dominguez wrote:

Scott, in part they could be taken as just different modules (or services), especially since the current implementation of the Payments BC is very simple as everything is mocked out. Our thinking was that this Payments BC would be owned by a different team altogether, and would not be coupled to the Orders BC with respect to data storage, nor full referential integrity and consistency between the two. So we would expect the Payments team to use their own UL if they want to. From my understanding, Evans suggests that the different teams alone is good reason to split a BC, and even more if they have their on boundaries in terms of data store they use.

In fact, even in this very simple version they do not share a UL (but they are not ambiguous as you mentioned, because of the fact that they do not overlap). If you look at the events and commands in the Payments BC, there is not a single mention of this being a part of a conference management system, where as the Orders BC is an ordering system coupled to the conference domain itself. You could reuse the Payments BC in different systems (assuming it was not mocked out), but not necessarily the other BCs we have.

What do you think?

Julian

On Mon, Jul 8, 2013 at 5:28 AM, Greg Young <gregor...@gmail.com> wrote:

I would say yes they sound like modules or dare I say services in a soa sense

On Monday, July 8, 2013, elbandit wrote:

Hi,

I don't understand why Payments and Orders are two different bounded contexts as there seems to be no ambiguity in the UL that is used within each of them. As far as I remember a bounded contexts boundaries are based on language. Aren't Payments and Orders simply modules (I think Udi calls these Business Components) of a Sales bounded context? Which would mean that the process manager is acting within the sales bounded context and all is good with the world. Also I understand that the process manager acts as the application level so it is valid to send commands as it is the client of the domain layer.

Scott

On Wednesday, 9 January 2013 09:11:22 UTC, Werner Clausen wrote:

Hi,

 

The CQRS Journey here: http://msdn.microsoft.com/en-us/library/jj591569, says that a Process Manager do not perform any business logic, and it should only work within a single bounded context. Yet the example on the same page shows:

 

1.  Process Manager routing between Order and Payment, but that is two different contexts right?
2.  Process Manager sending an "AddToWaitList" command as a reaction to the "SeatsNotReserved" event, but that is business logic right?.

 

And while we're at it: Is there a clear separation between a Process Manager and a Saga? 

 

--
Werner

--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kijana Woodard]

"the Payments BC ... if created by a different team then it should be a separate BC"

Isn't this Conway's Law playing out?

[Julian Dominguez]

@Scott: I'm not sure if I can generalize it, but yes, that is the path WE took in this case for partitioning our system.

@Kijana: It well may be Conway's Law, but this is a real aspect of software engineering, whether we like it or would prefer a bigger unique model. Even Eric Evans grants this as a valid way of partitioning BCs in his blue book.