,
17 tweets,
15 min read
Read on Twitter
@HaripraghashS @HaripraghashS 2 short questions without 2 short answers 😅But let's try! Projections for me when I started my journey with #EventSourcing was the hardest thing to understand. I thought: ok, I can rebuild the aggregate state by replaying events one by getting them by id 1/
@HaripraghashS Having that I'll have the state of the single aggregate. Wait a minute! If I won't to do that for the aggregate list then I'd need to get all events for those aggregates and reply it one by one? Nah that's can't be! For that we have we have projections. As you for sure know /2
@HaripraghashS What are projections? It's just representation and interpretation of the set of event. What's more when we're replying events to get aggregate state - that's also projection. It's easy to forget about that because it's default case. We're just interpreting events to get state /3
@HaripraghashS Going back to your question, having the knowledge that default state reply is just the projection. Then building projections from events from the different aggregates is the same. Let's go to real world sample. Let's say we have 2 aggregates BankAccount and MoneyTransfer /4
@HaripraghashS BankAccount has Id and Number, MoneyTransfer has Id, FromAccountId, ToAccountId and Amount. What could be projection for that state? Eg. BankAccountBalance where we display Number and Balance. Then based on the events like BankAccountCreated, MoneyTransferConfirmed /5
@HaripraghashS We can project them based on the BankAccountBalance. All of those events needs to be correlated somehow. This correlation will be made on BankAccount - Id, MoneyTransferConfirmed - FromAccountId, ToAccountId. Id of our projection will be AccountId. /6
@HaripraghashS How to trigger projection rebuild? It depends of the tool and storage that you're using. In #Marten, as we have postgres underneath we're storing all events from a session as UnitOfWork and applying all of the events to projections that can handle them jasperfx.github.io/marten/documen… /7
@HaripraghashS How we're finding them? In the projection definition we're specifing how to get projection id from the event. So for BankAccountCreated it would be AccountId, for MoneyTransferConfirmed it will be the FromAccountId, ToAccountId (we'll be updating 2 projection items at once!) /8
@HaripraghashS We're storing projections as key/value documents (in Postgres Table). So based on the field from events we're getting the document with the Id, updating the logic based on the Apply method definition and storing that in back as the document. /9
@HaripraghashS That's simple pattern that could be used also for other cases eg. updating read model in @elastic - you're getting event from the Event Bus (eg. @apachekafka, @RabbitMQ), you're modifing your index based on your specificed custom logic /10
@HaripraghashS @elastic @apachekafka @RabbitMQ There are also other options - eg. triggers based on the updates to your stream table, using CDC mechanism, etc. So you need to find good tool for your storage, technology and the business case, but patter would be the same /11
@HaripraghashS @elastic @apachekafka @RabbitMQ Regarding you're second question. If you're asking about how to find the Id of the stream, so eg. whether to have the same Id for all MoneyTransfers from the BankAccount or have single Id for each MoneyTransfer then as always: "it depends" 😆 /12
@HaripraghashS @elastic @apachekafka @RabbitMQ What I may say for sure is to keep Aggregates as much autonomous and as simple as possible. Keeping boundaries in Aggregates modelling is the most important things. So in general I'd suggest to make MoneyTransfer a separate aggregate instead of grouping it by Account /13
@HaripraghashS @elastic @apachekafka @RabbitMQ Regarding storage - it also depends 🙃In Marten we have one table for all events (indexed by streamId), @PostgreSQL can handle easily huge number of records. You can also make sharding later. @apachekafka keeps events per topic - so business split /14
@HaripraghashS @elastic @apachekafka @RabbitMQ @PostgreSQL Both options are fine depending of your needs, workload etc. As I wrote when you're working with #EventSourcing or DDD then you're taking the red pill and you need to consider the real world cases. That's generally better, but also more demanding /15
@HaripraghashS @elastic @apachekafka @RabbitMQ @PostgreSQL @HaripraghashS I hope that it answers your questions. If not feel free to ask! We have also quite nice community on our #Marten gitter channel gitter.im/JasperFx/marten feel free to join there. There are also other experienced people there answering also general questions 🚀/16
