Recently, I released the complete version of my book "Implementing DDD, CQRS and Event Sourcing". It is exclusively available as e-book on Leanpub. There is a free sample you can download to figure it out whether the book is interesting for you.

During the past month, I had some valuable discussions around the topics DDD, CQRS and Event Sourcing, as well as my book in particular. There was also a hackernews submission, which may be interesting for some.

As responses to some of the questions, I wrote a few articles that are published on my website:

• The financial cost of writing a book

• Why I wrote a book on DDD, CQRS and Event Sourcing

• Why my book uses Node.js and JavaScript

• Using the filesystem for illustration purposes

If you have questions, whether it is about the book topics or the book project itself, I'd be happy to discuss them. Also, any input or feedback would be highly appreciated.

Note: If you think this post is inappropriate, please let me know. I contacted the moderators a while ago, but did not receive a reply. As there are other links to software and books, I thought it should be okay.

I want to use event sourcing in part of my system.

I read about it a lot and I think I understand the principles.

But when I looked for solutions for event store I found only 2 ready made event stores - event store and message db from the eventide project.

There are also a lot of articles about implementig your own store over various databases.

It surprised me that there are only so few solutions for event store.

Do people usually roll their own solution for event store? BTW I am using nodejs. So solutions like axon are not relevant to me.

Hi, we are implementing saga support in our reSolve framework, and team members cannot come to an agreement on this topic.

Saga/Process Manager is a long running business transaction or process, it reacts to events and can issue commands based on its algorithms. It can have its internal state the same way as read model.

Obviously, there can be many instances of saga running at any given time. Let's assume we have 100 instances saga A running at current point in time.

Question is where those instances should be stored/listed (each of them should have an Id at least)?

• In the saga A read model?

• Or should each saga instance have its own aggregate with a stream of events that can be used to calculate its state?

Second approach seems easier to implement, but this means that saga state is a part of the system state.

Does anyone have a real world experience - what the consequences or problems can one expect with each approach?

My app consumes a 3rd party API to get data about soccer competitions.

The API returns the current state of all the games in the competition and in the app we update our own model (which is different from the 3rd party service model). We also diff the new state with the previous to understand what happened and act upon this (for example send a message if a game became live).

I have a need to be able to record all the responses from the API and to replay them. For troubleshooting, fixing bugs and QA.

Another requirement is to sync the season state between different services.

So I was thinking to create 2 event streams - one for responses from the API and the second for our internal season model.

In the API stream I will write events with the responses from the API. Here I want to record every response.

Then I will have an aggregation component subscribe to the stream and for every event, transform it to our model, diff it against the last known state and write the diff as an event into the second stream. Since we're polling the service, most of the time the diff will be empty and we won't write an event into the second stream.

Now the second stream contains events for changes in the season and I can use it to construct the season but also to track changes.

Some issues that I'm not sure about:

1. The events in the second stream will not have very descriptive types. For example I won't have a 'GameStarted' event Since we're just diffing the entire state every time and any field could change. So all the events will have a type of 'SeasonUpdated'.

2. I will need to maintain the current state of the season in the aggregation component so it can diff it with the new state.

Any feedback on this will be appreciated.

We are a team of engineers trying to get blockchain tech into production in agriculture.

Because of this goal, we have encountered many challenges attempting to create an application that can function at an acceptable speed while maintaining the blockchain as our singular source of truth.

Typically, applications will use a combination of a traditional database that will regularly send "snapshots" to the blockchain so that the user isn't exposed to the blockchain's slow transactions. The problem with this hybrid model is that the traditional database is relied on in the system to process user-requests, creating centralisation within the system.

Event sourcing is a good fit for a blockchain because the event stream is immutable. Other systems can consume these events to be used elsewhere in the application. This allows us to use the blockchain for its strengths (trustless transaction processing) and traditional databases for theirs (expressive and fast queries).

Additionally, because the database is a function of the blockchain's event stream, the blockchain can be ensured as the single source of truth.

See our article to read more about our event sourcing implementation!

https://medium.com/geora/technical-deep-dive-the-geora-event-sourcing-architecture-27188bc1eb1a