Communicating multiple statuses of an aggregate using an event

[radhakris...@gmail.com]

Hi,

     Since instances of our services( a single BC like Order ) are distributed (e.g) Kubernetes  we are not able to extract the correct state from our DB. 

Multiple transactions together constitute an aggregated state.(e.g) Multiple order lines

changing state for placing one order.

So at a point in time we are not sure if all the order lines have the correct status. So we have to emit an event when an instance of a service changes the state of a particular order line. We plan to have a snapshot of the statuses in the event.

When any instance of a service receives all correct statues the order can be placed by

that instance.

 This is coordination among instances using a snapshot event. Is this a known pattern ?

Is there any recommendation ?

Thanks.

[Tomas P.]

Hi,

How does the process of changing multiple order lines work? Why is this change distributed to multiple services?

Does the change originate on the frontend(UI) or in other services?

How does the API of changing an order look like?

Best Regards

Tomas

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/8aceab93-fded-40b8-a7e4-24e8406be7b4n%40googlegroups.com.

[radhakris...@gmail.com]

>How does the process of changing multiple order lines work? Why is this change distributed to multiple services?

      The change in status is received from an external service. The distributed nature of services is for availability and is a technical

design concern.

>Does the change originate on the frontend(UI) or in other services?

      The change in status is received from an external service.  

>How does the API of changing an order look like?

If all the statuses of the order lines are 'READY' then the Order status becomes 'READY'. It is a status process manager

but the state machine is in the DB. An event at any  point in time with all order lines in 'READY' state could be a trigger.

Otherwise every time an order line changes status there are calls to get all statuses from the DB. 

Thanks.

[Ben Kloosterman]

"So at a point in time we are not sure if all the order lines have the correct status." 

??? This is how eventual consistency, async or event driven work. The alternative is locks and sync calls which dont scale.

Why not simply create a separate read service which also gets the events and builds up the state and fires order changed. This pattern is very useful for consumers external to the team as they dont and shouldnt know your lowler level events. Its still async .

I normally use solutions that guarantee related data goes to the same instance to avoid locks ( eg partitioned stream) 

" This is coordination among instances using a snapshot event. Is this a known pattern ?"  not that im aware of. 

Ben

--

[radhakris...@gmail.com]

>" This is coordination among instances using a snapshot event. Is this a known pattern ?"  not that im aware of.   

I was of the opinion that when a snapshot of the change( or no change due to failed business rule ) which is same as the event

is published we can reconstitute or audit that event.

So everytime we publish the change as an event we have more control over the reconstruction.

Thanks.

[Ben Kloosterman]

Have you had a close look at simple CQRS  how does this not meet your requirement? That will help us understand better., 

Basic event sourcing peeling back all the fancy stuff is just the bank account pattern .,,. Load the transactions and dynamically calculate the value .  This transaction log is always the most accurate and the "state' IS the collection and dynamic logic of the events.  Spapshots and event retention is independent some systems keep all events for ever , others use Snapshot + events  , others keep them for a relevant period and roll over to data ( eg accounting systems)

A bank will do monthly roll overs in statements these are "snap shots" and  NOT correct and accurate you can always get an adjust eg a transaction for last month arrives  40 days late , they are basically a convenience  but the transaction log is the source of truth. 

"So at a point in time we are not sure if all the order lines have the correct status." 

Dont really understand what you mean by this , is it because your using an eventually consistently read domain ? Why do you need to know the correct status ? Do you need to do a mutation ?

If I understand you right In most cases this is done via an order completed event,  The write domain is always correct 

 Ben

[Mohan Radhakrishnan]

>Dont really understand what you mean by this , is it because your using an eventually consistently read domain ? Why do you need to know the correct status ? Do you >need to do a mutation ?

>If I understand you right In most cases this is done via an order completed event,  The write domain is always correct   

That is correct. I need to 'PUBLISH' the order when all eventually consistent order lines are received. And we don't separate the read

service from the write service completely. 

Multiple instances of the service are listening.  So I just need to rely on the Order completed event for now. Choreography instead

of orchestration.

Thanks

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAJT18iYJqROMGY6M_Y7gdkmwji%3DjFtSm0Wg332d0PeTFqXpauw%40mail.gmail.com.