search

kgrzybek / modular-monolith-with-ddd

Full Modular Monolith application with Domain-Driven Design approach.
MIT License
11.12k stars 1.75k forks source link

More Clarity in Event Sourcing Approach #163

Closed kacey90 closed 3 years ago

kacey90 commented 3 years ago

Hi, The project is getting huge and interesting. But one quick question; I noticed that all data created in the database in Payments module alone only get stored in payments.Messages table with the stream stored in payments.Streams and not in their respective tables in the DB. Is this the new behavior?

I ask this because I tried exactly this approach in a work project and got the above behavior.

kgrzybek commented 3 years ago

Hi @kacey90,

The payments module was redesigned from the traditional persistence approach (current state only) to Event Sourcing at 2020-07-11.

So yes - the module state is kept as a stream of events (Messages, Streams) and the rest of the tables store read models data or some infrastructure related data (outbox table, internal commands etc).

kacey90 commented 3 years ago

Hi Kamil,

Yes I understand the concept. I later figured it out. Apologies for not reverting and closing the issue. I noticed some entity projectors implementing IProjector. That's how you update the tables in the database. Great stuff 👍🏾