Hey,
I am actually interested in Event Sourcing for literally years but haven’t used it yet. Last night, I read through the guides in the Commanded documentation and watched the linked 20 minutes talk on Youtube.
The provided examples start to make sense and the overall picture becomes more clear.
Now, I have a project idea in mind for a very long time, which involves a rating system. I knew right from the start that this rating system would be a good opportunity to use Event Sourcing. However, this rating system will be a little bit more complicated in terms of aggregation and business rules.
Let me show you the concept:
The following will be my logical structure:
- parent
--- child
------category_a
------category_b
------category_c
--- category_1
--- category_2
--- category_3
-
parent and child are the actual things I want to be rated.
- a
child has a dynamic list of categories to be rated on, that can change over time, so they have just an identifier, e.g. usability (%RateCategory{subject: "id-of-child", name: "usability", score: 8})
- a
parent also has a dynamic list of categories to be rated, same as child
- some parents are not ratable, depending on their type
- the overall rating of a
child is a combination of all category ratings for it
- if a parent is ratable, it has two overall ratings
- one overall rating as a result of combining its category ratings
- another rating that combines the overall rating of its children
Here comes the tricky part:
I want to have the concept of rating periods. I am not sure yet how long a period should be, but as soon as one period ends, another starts immediately. This is to track “progress” over time.
In each rating period, a user can rate only once.
Let’s say, there is a rating period every month. In January, a user can rate all categories of a parent and child. Then, in February, the ratings will be “reset” and the user can rate for everything again.
The goal is to track the ratings of a parent and child over time to see if things got better or worse.
So, that was my overall idea for the rating system. Everything else in the system will be done the “usual” way.
What I would like to get from you are some strategies to achieve this. Since I am just starting to get into the ES mindset, I am a bit lost as to how to implement this right now.
4 Likes
I’m a bit drunk right now. And I’m probably not reading this right. lol
And since I’m drunk and bored, I threw up a start app for you. I had all aspirations of understanding what you’re after. But nope.
I hope this sets you off onto the right path.
https://drive.google.com/file/d/1iiY6A1uHfCeoZiCxLVGm2wo_lJF9jwaQ/view?usp=sharing
It sounds like you want to implement your entities’ lifecycle to be within a time period. You can take inspiration from accounting where a ledger is for a given period (e.g. one year) and at the end of each year the ledger is closed. When this occurs the ending balances from the ledger are copied across into a new ledger as the starting balances.
You could design your entities’ event streams to be monthly and at the end of each month have a scheduled command end the rating period and raise a corresponding domain event. This can be used to start the next period:
- Whenever a rating period is started, it schedules an
EndRatingPeriod command to be executed at the end of the month.
- The scheduled
EndRatingPeriod command gets automatically dispatched at the end of the month.
- This produces a
RatingPeriodEnded event.
- Which triggers a
StartRatingPeriod command to begin the next month’s ratings
Include whatever data you need from the rating period in the period ended event so that it can be included in the command to be copied into the new period. For example you might just copy the average rating per category, not each individual rating.
Commanded scheduler can be used to do the above command scheduling (either using an event handler or process manager).
By splitting the entities into time-delimited event streams (e.g. monthly) you can use read model projections to build aggregated views of the ratings over time. The benefit of this approach is you won’t have unbounded event streams for your entities and limit the number of events within each stream.
3 Likes
Yves Reynhout gave a good talk at Explore DDD in 2017 which covers splitting aggregate event streams by time (appointment scheduling product for healthcare).
3 Likes
Using an extra RatingPeriod aggregrate was also one thing I had in my mind, I just wasn’t sure if this was the correct thing to do, but it gives me the most flexibility I think, because I can end a rating period whenever I want and seamlessly move from 1 month to 1 week if I want and still retain the old 1 month cycles for history.
So, let me dump my thoughts in here:
- I have a
RatingPeriod aggregate with a minimum of id, start_date, end_date, is_active fields.
- I have
Parent and Child aggregates whose identity is a compound value consisting of the parent/child id and the RatingPeriod id. Probably using a custom struct like in the documentation example for custom identities.
- When I want to commit a new rating, I first fetch the current active rating period from my read model and include its id in the rating command and event.
That should give me all I need to properly structure a read model. I aim at having one table row per parent/child entity and rating period with a json column for the categories and its rating counts.
I will also watch the talk you linked. Maybe I missed something but right now it starts to make sense and takes shape in my head.
