Event Sourcing – Part 1 – Beginning with a clean slate

Event Sourcing has come up for a while and it is a really interesting idea but I have never implemented it from “nothing” to “something” to capture my own thoughts and reasons for doing a certain thing or not.  Event sourcing is simply where you capture all the events that make up all the things that happened to the item being tracked to deliver it to it’s now current state.  You can replay all the events, like a big journal, in order and always get the same state or end result.  Many examples out in the world show a comparison to a person’s bank account or to an accountant’s general ledger.  In these examples you do not just store a total or a customer’s account balance only, you would store all of the credits and debits that make up the current balance.  Further, if there was an error, you would never remove an entry but establish a new event that would correct the error while leaving the detail in the event history.   So our events that make up history must also be immutable and reading through them multiple times will always produce the same end result.

I have been reading about the topic of Event Sourcing and listening to different videos on the subject to gain a more general sense of the concepts to see what others are doing to solve their problems with this method.  A common name that appears in this space is Greg Young, with his talks on CQRS and Event Sourcing, he has put quite a bit of information out there on the subject.  There were many other articles and discussions with colleges about this subject as well from a conceptual standpoint.

I want to step forward a bit, out of the concepts, now that I have a very high level academic understanding and try to take my somewhat jumbled thoughts on the subject and apply them to solve a problem using Event Sourcing.  I expect that the end result of my solution will evolve quite a bit over time but I want to work through the different parts and understand why I am deciding to “do” a certain thing.  It is easy to anticipate problems and create a solution for them…  but, sometimes I end up spending quite a bit of time creating a solution for a thing that might happen during a certain edge case and not directly solving the obvious problems first.  My goal will be to build an Event Sourcing example from a clean slate and create a solution for the problems presented along the way, while sticking to the items that I feel are at the core of solving the problem.

Since I am in the Nashville area and there is quite a bit of healthcare influence here, I will deviate a bit from a traditional Event Sourcing examples and will look to create a solution for the problem domain of admissions, transfers and discharges of patients in a healthcare facility.  I would like to model a floor of a building with multiple rooms, that patients will be admitted into, then moved around over time and finally discharged.  Some patients will be readmitted and some will be new patients during the process.  Each patient will consume resources and will have services rendered that will need to be billed for.  The goal in the example is to add enough “real world” items to make it a bit more thought provoking while I work to test out the potential solution.

One of the big goals for the solution will be to answer various questions at any point in time for a patient, service provider or from the perspective of the room that was occupied.  I will forgo any notion that I am creating this solution for scale and will instead attempt to create the solution with the the most minimal items necessary.  Since I have quite a bit of experience with MS SQL, I will create the initial solution and schema with this more traditional relational store.  Then, will look to move on to a JSON document based solution to solve the problem afterward.

My next article on this subject will establish many of the necessary components that we will need and the items that we will model in the context of our simple healthcare solution that I will refer to as “Patient Tracks“.  Then we will define the boundary and scope around the models so that we can limit the problems that we are initially trying to solve.  This scope will grow outward over time but my hope is that we can establish the minimum items necessary to begin creating the early stage of our solution.  I hope that as you read, you will leave comments and ask questions so that we can establish this solution together and understand the “why” for implementing something.  Also, this exercise will be useful to me (and hopefully others) as we move through the problems and attempt to solve them with Event Sourcing.





About b.hedge

i do database stuff and i like to solve business problems with code.
This entry was posted in cqrs & event sourcing, mssql and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s