Handling an event which originates from an aggregate in a different service.

Imported from Google Groups
#1

Hi there,

Suppose there are 2 microservices at play. Service A and service B. Both have their own set of aggregates, let’s say service A has FamilyAggregate and service B has HouseAggregate (both are event sourced).

At one point, FamilyAggregate generates an event, called NewChildBornEvent. HouseAggregate on the other hand, holds information about the number of occupants in the given building (because internally it’s used to do some calculations and conditions for it’s own commands; whatever - it needs that piece of information).

How can HouseAggregate update it’s internal state, when a new child is born? I can think of 2 possible solutions:

  1. Service B has also an @EventListener method for the NewChildBornEvent, which in turn issues a UpdateNoOfOccupantsCommand that HouseAggregate listens on, and that in turn generates OccupantsUpdatedEvent, which finally sets the internal state.

So you’ve got:

FamilyAggregate -> NewChildBornEvent -> EXTERNAL_EVENT_LISTENER -> UpdateNoOfOccupantsCommand -> HouseAggregate -> OccupantsUpdatedEvent

This seems like an overkill.

  1. Less likely scenario, is to bring those two aggregates to one service and either make one an aggregate member of the other, or create a new aggregate and make both FamilyAggregate and HouseAggregate members of the new aggregate.

This doesn’t seem like a universal solution however, as one can easily imagine a scenario where there will be 2 aggregates such that it makes no sense putting them together.

For the lack of better ideas I’ve been practising the 1. solution. I just think there should be an easier way to do this, like HouseAggregate listening directly on NewChildBornEvent. Perhaps I’ve missed the trick somewhere?

Let me know how you practise similar scenarios and maybe point me to a better solution. Thanks

#2

Hi Konrad,

There is no trick to directly listen to another Aggregate it’s events, as that’s not an option to begin with.
The Aggregate is your command model, meant to deal with command messages and it’s own event messages.
It will only handle it’s own events, as that’s what it’ll need to source itself from the given aggregate stream (differently put, Event Sourcing).

To the options you’re giving, both are viable, but it depends which works best in what scenario.
This mainly comes down to how your Domain is set up, and how you Model your messages, command and query models based on that.
There are very likely plenty of example where the Family and House entities belong to the same Aggregate Root, thus allowing you to go for option 2.

But I can imagine that both could also belong to dedicated bounded contexts within the domain, thus opting for them to be dedicated Aggregates.
This would thus require you to go for option 1.

Without knowing the actual use case you’re not feeling to comfortable with right now, my hunch is however that option 1 is the way to go for the correct decoupling.
It might seem overkill, definitely at first, as you’re creating more components than you’d expect to ‘just increment the number of occupants’.
This is however a means of pulling both contexts apart, which eventually allows you to split of the services in to different teams, different (micro) services, different repositories, etc.

So, lots of mumbo jumbo here. The short answer to your question would be, ‘it depends’.

That’s my two cents.

Cheers,
Steven

#3

I definitely agree, that in the scenario prescribed here both options are viable and without knowing the intricacies of my domain it’s hard to recommend one over the other - I totally get that. I was really just gauging if my thinking is correct.

Thanks for you time.

#4

Hi Konrad,

Understandable that you wanted to spar with somebody else about this.
Very worthwhile and very important to discuss this process.

I tend do bother a lot of people prior to actually setting some commands/events/queries/aggregates in code.

No worries, and I assume we’ll hear from you again!

Cheers,
Steven