We have one system with event sourcing in production for a few years now, and a couple more in development. I have an observation to share if you would entertain it.
The conditions of this challenge can help the participant understand the necessary mechanics of event sourcing. However, it is not likely to demonstrate a high value use of event sourcing. In this scenario, the business events more or less line up with the data-oriented storage semantics. So there will be little advantage from modeling with events. One exception might be if auditability was a top priority.
Rather, a high value use would be one where the business event had no clean mapping to a single data update. It is very common for business processes to have events like this. For example, what happens when a student withdraws from a course in college. The relationship between student/course/semester cannot just be deleted. It still has to be recorded that they withdrew (maybe for tuition reimbursement). It isn't simply a final grade of W because it has different rules from receiving a final grade at the end of term (like GPA calculation). And so on. Using events in this scenario allows you to focus on the important use cases and the events they produce. Then you can be adaptable in how the app uses that information. (Triggering a reimbursement evaluation; triggering a full-time eligibility evaluation; removing from class roster; adding to transcript; etc.)
Anyway, I hope what I am saying makes sense. I wanted to mention it because I have seen people try event sourcing and come to the conclusion that it is an over-engineered way of storing data. And for their usage it may have been. For this challenge, people might draw similar conclusions if they are unaware that the exercise emphasizes mechanics rather than fitness for the subject matter.
Thank you very much for your insightful comment! I agree with everything you're saying and will update the document to add more information and make clear that this is mostly about the mechanics, not the usefulness of the particular example (but adding auditing as a reason to do this certainly wouldn't hurt )
I really appreciate you taking the time to share this, thank you!
It looks great! I think the club scenario is a really strong one. It is not too complicated, but you can do interesting things with it such as an account history.
I created an implementation of the Contacts List use case in Java, as it was a nice way to get started: here. If I find the time, I will also have a look at the Clubs use case.
I'm really interested in your feedback. Yours as well, Kasey.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love this challenge. Thanks for hosting it.
We have one system with event sourcing in production for a few years now, and a couple more in development. I have an observation to share if you would entertain it.
The conditions of this challenge can help the participant understand the necessary mechanics of event sourcing. However, it is not likely to demonstrate a high value use of event sourcing. In this scenario, the business events more or less line up with the data-oriented storage semantics. So there will be little advantage from modeling with events. One exception might be if auditability was a top priority.
Rather, a high value use would be one where the business event had no clean mapping to a single data update. It is very common for business processes to have events like this. For example, what happens when a student withdraws from a course in college. The relationship between student/course/semester cannot just be deleted. It still has to be recorded that they withdrew (maybe for tuition reimbursement). It isn't simply a final grade of W because it has different rules from receiving a final grade at the end of term (like GPA calculation). And so on. Using events in this scenario allows you to focus on the important use cases and the events they produce. Then you can be adaptable in how the app uses that information. (Triggering a reimbursement evaluation; triggering a full-time eligibility evaluation; removing from class roster; adding to transcript; etc.)
Anyway, I hope what I am saying makes sense. I wanted to mention it because I have seen people try event sourcing and come to the conclusion that it is an over-engineered way of storing data. And for their usage it may have been. For this challenge, people might draw similar conclusions if they are unaware that the exercise emphasizes mechanics rather than fitness for the subject matter.
Best wishes to everyone on the exercise!
Thank you very much for your insightful comment! I agree with everything you're saying and will update the document to add more information and make clear that this is mostly about the mechanics, not the usefulness of the particular example (but adding auditing as a reason to do this certainly wouldn't hurt )
I really appreciate you taking the time to share this, thank you!
I just rewrote the document based on your suggestions and am interested in what you think about the changes - but only if you'd like!
It looks great! I think the club scenario is a really strong one. It is not too complicated, but you can do interesting things with it such as an account history.
I created an implementation of the Contacts List use case in Java, as it was a nice way to get started: here. If I find the time, I will also have a look at the Clubs use case.
I'm really interested in your feedback. Yours as well, Kasey.