Question regarding cross-domain notifications

EventStoreDB
#1

.Hi guys,

I’m trying to understand how to design a specific cross-domain notification using EventStore (I am guessing using projections).

Here is a simplified example of what I am trying to model

  • imagine that there are 2 domains - an HR domain and a Payroll Domain, containing aggregates

  • I would imagine that both of the domains are modelled with their own aggregate streams

  • Sally gets married, and so the HR Manager changes her name from “Sally Smith” to “Sally Jones” - an EmployeeNameChanged event is captured into the aggregate stream in the HR domain

  • I would like to subscribe to the EmployeeNameChanged Event in the Payroll Domain, so that I can update Sally’s name in the Payroll Domain
    How would I go about doing this? I imagine that I would want a “linked event” to be projected into the aggregate stream in the aggregate stream in the Payroll domain…otherwise the event/notification may appear out of order when rebuilding current state (i.e.: if a separate stream were used).

  • Is this good practice/design (the payroll domain would obviously become dependent on the HR domain’s event schema)?

  • are projections the best mechanism for doing this?

  • what alternatives exist for modelling event orchestrations between dependent event-sourced domains?
    [RB]

#2

Ryan,

Are you maintaining aggregate state in proejctions, or something like C#?

If you are using C#:

You could create a persistent subscription on $et-EmployeeNameChanged (or a catchup) and consume the event in some REST service, where you could update the other aggregate.

I am

#3

Alternatively, when there are a lot of changes type you care about in the other applications :
send a notification “Hey_Something_Changed_In_HR_That_You_Might_Be_Interrested_In” with the Id of the Person.
and make a feed in the HR systems where you have the latest state of the Person ( so in this case with the new Name) as well as thx last x events of the Entity
the consumeong system can choose to anly work on the Document or the events

#4

Thanks Steven - I had the same thought…you would then need some kind of idempotency check in order to avoid replaying this event and re-writing a change to the aggregate stream in that event? What would be the best way of doing that - re-using the event guid from the originating event?

#5

PS: yes - using C#

#6

how would you consume this feed in a controlled fashion, interleaving the events with the target aggregate stream? It seems that you would almost want to have a process manager, which would be able to consume the feed from the source domain (HR), and issue a command to the target domain (Payroll) - so that the representative event is now contained in the target domain’s aggregate feed (and would be relayed appropriately when rebuilding state). The caveat here would be that Process Manager would need a way to determine if a “notification” had been processed previously, or not…

#7

Ryan,

In our aggregates, we rhydrate all the streams events into a HistoricEvents[] and simply verify the Eventid hasn’t already been applied.

This is purely a belt and braces since the stream itself would be idempotent.

So, our system works this way:

  1. Write to Aggregate

  2. Event gets emit and we deliver it via Persistent Subscription to another REST endpoint

  3. REST endpoint rehydrates second Aggregate (which lifts all previous events)

  4. Add the event to the aggregate

  5. Save would block duplicates

I know what it’s like doing this stuff, and getting hold of other people to chat to is quite tough, so if you want any more detail, just give me a shout and I can try to help out.

#8

Position

#9

source domain (HR), => the target domain (Payroll) is an event ( just a change notification )
=> the target domain does whatever it wants with the noficiation ( query some read momdel from source domain, nothing, …)
=> the source domain maintains a read model with the latest state in any form , as with any projections,

no process manager involved

if ever the target system is miisng notfication ,

you can alwyas fire them up from the source system

#10

( sorry for the typos )

#11

thanks for the info everyone - I’m going to try and set up a small POC to experiment with the model. I’ll share once I’m done - in the interests of furthering the discussion