Brokers and buses are a specific technique used to solve communication. Event sourcing is a architectural approach. In a lot of platforms based on event sourcing you will find brokers.
You usually do these 2 in a transaction, eg you store the event to be published inside the database alongside the actual event, and then it's guaranteed to be published, and once its published it can be removed from the database. If it fails to publish it can retry as many times as needed
Even though your video is very good. I feel that Axon unnecessarily made is too complex. The same fields are copied everywhere. Its more confusion and tests will take forever to write.
![อิสราเอลโดนอิหร่านถล่มหนักกว่าที่คุย : [คุยผ่าโลก worldtalk]](http://i.ytimg.com/vi/R8gIN-MQhWw/mqdefault.jpg)
the session was clear and well structured. thank you.
Before running the java application do we need run the axon server?
Allard Buijze, is there source code or sample code to refer?
So basically Axon Framework is kind of like JavaScript's Redux on steroids?
Would you mind in sharing link to source code?
how is that different from all that plethora of message brokers/enterprise buses? Seems like Axon reinvents the wheel
Brokers and buses are a specific technique used to solve communication. Event sourcing is a architectural approach. In a lot of platforms based on event sourcing you will find brokers.
17:08 What if your persist operation succeeds but publishing fails or vice versa?
You usually do these 2 in a transaction, eg you store the event to be published inside the database alongside the actual event, and then it's guaranteed to be published, and once its published it can be removed from the database. If it fails to publish it can retry as many times as needed
Even though your video is very good. I feel that Axon unnecessarily made is too complex. The same fields are copied everywhere. Its more confusion and tests will take forever to write.
Event Sourcing can be done using axon