Mapping general building blocks of business processes to axon framework concepts

Imported from Google Groups
1

Hi there,

I try to fathom out some use cases of the axon framework inspired by a more general sight on business processes. I will take the following general building blocks into account for this discussion:

1.) Intention

An actor uses information to assess the current situation. This leads to a decision on acting and express his intention to change something. The intention is expressed by a new emitted command.

2.) Business rule

A business rule is triggered by a command. Once triggered the business rule takes a list of events from the event store to project state from it. Based on the state the business rule is evaluated. The result of the evaluation is an emitted list of new events.

3.) Interpretation

An interpretation takes a list of events from the event store to project information from it.

4.) Automation

An automation is triggered by an event. Once triggered the automation evaluates the event. The result of the evaluation is an emitted list of new events and commands.

The question now is, how can these building blocks mapped to axon concepts?

The motivation for this is, that you will find this or similar building blocks if using e.g. event storming upon exploring your business cases. I want to postpone the concrete technical mapping as late as possible also knowing that there could be several axon concepts to be mapped from the same general building block.

2

Hi,

these concepts map pretty cleanly to building blocks in Axon (or CQRS & EDA based architectures in general).

  1. Intention -> Command
  2. Business rule --> Aggregate (or command handler bean)
  3. Interpretation --> View model (which is updated/maintained by @EventHandler methods)
  4. Automation --> Saga (or @EventHandler bean if no state needs to be maintained in between Events)

The reason for this clean mapping is probably the fact that the inventor of Event Storming (Alberto Brandolini) also applies CQRS & EDA (and Axon) to his projects and the process conceived to help him design the process, but without forcing any implementation to the design.

Cheers,

Allard

3

Hi Allard,

thanks for your hints. But I would like to discuss the not obvious mappings. My point is that for the building blocks there are more than one solution. Let’s give it a try.

  1. Business rule → Aggregate (or command handler bean)

Part of the business rule is to build state from events. This building block has no restrictions on the list of events taken into account. Functional people would call this a projection or left fold. An aggregate is a special projection working only on the events belonging to the same aggregate identifier. So what other solutions can you think of?

Having a shared kernel (from DDD) seems for me to be another possible solution to implement a business rule. Right?

An axon saga could also be used as another special projection working on events from more than one aggregate but the selection of events is restricted by the associated values.

A command handler directly asking the axon event store, making projections with the Java 8 stream api and emit events would be another solution. This seem to me a solution with the least restrictions.

Can you think of other solutions possible with the axon framework?

  1. Interpretation → View model (which is updated/maintained by @EventHandler methods)

Right. One possible solution. Are there others?

  1. Automation → Saga (or @EventHandler bean if no state needs to be maintained in between Events)

Both solutions can also do a projection each time the event is received, right?

The reason for this clean mapping is probably the fact that the inventor of Event Storming (Alberto Brandolini) also applies CQRS & EDA (and Axon) to his projects and the process conceived to help him design the process, but without forcing any implementation to the design.

:slight_smile: Yes, this is exactly why I want to have this discussion.

From starting in that direction I’ve learned that developer and also lots of domain experts first jump on structure, like seeking for aggregates first and thinking of data instead of behavior. Therefore event storming experts tell you to explore the behavior first. If aggregates naturally derive from that, that’s OK. But they also write e.g. the data (events) needed on the cards for business rules. Sometimes you cannot find any good aggregate bounds then.

The functional people are fine here. They just program the projection. Transported into the object oriented world, this seems to me, that in that way of thinking you give up the concept of aggregates as protectors of a (possibly big) set of invariants. Instead they give each independent invariant a meaning. This also seems to me the more flexible approach to get working solutions. What do you think? Should the axon framework be used like that?

Thanks for joining this discussion,

Frank.