0

I have done a lot of reading about Event Sourcing in my spare time recently.

I understand that it is for situations (Bounded Contexts?) where the business is interested in how an entity arrived in its current state. The classic example is a bank, which would not store your current balance, but instead a collection of debits and credits, which show how your balance was arrived at.

I was looking at some code recently. Please see the DDL below:

CREATE TABLE Query (ID int IDENTITY, User ID int, Salary int, Deposit int, Term int, value int, primary key (ID)) CREATE TABLE Mortgage (ID int, Description VARCHAR(30), primary key (ID)) CREATE TABLE MortgageQuery (QueryID int foreign key references Query (ID), MortgageID int foreign key Mortgage references (ID), PRIMARY KEY (QueryID, MortgageID))

A Person is offered mortgages based on their Salary; Deposit; term; house value etc (among others).

A user could query multiple times like this:

INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,35000,30,150000) INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,38000,30,150000) INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,25000,30,150000) INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,35000,25,150000) INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,38000,25,150000) INSERT INTO Query (UserID, salary, deposit,term,value) values (1,30000,25000,25,150000)

Notice that the same user (1) has queried multiple times with different criteria each time. Here it is not as if the term has arrived at 25 years or the deposit has arrived at 25,000. Therefore I do not believe this scenario would benefit from Event Sourcing/Event Store. Have I understood this correctly?

Improve this question

1 Answer 1

Reset to default
3

Have I understood this correctly?

It's hard to tell, in part because you are working from the implementation, rather than from the problem that you are trying to solve.

I understand that it is for situations (Bounded Contexts?) where the business is interested in how an entity arrived in its current state.

Almost; I represent that it is more correct to say that it fits situations where support for temporal queries has business value.

The common approach to persistence is that our data "now" overwrites our data "before". That severely limits the kinds of questions you can ask.

Examples of temporal queries

  • What was true at 12:34 yesterday afternoon?
  • What was true after we received 200 messages?
  • What was true when we received message { id: 12345 }

If you need a familiar analog - consider a source control system, and it's ability to answer questions like "what did this code look like before I broke it?"

So if temporal queries have value, then persisting events is one way to achieve that.

Improve this answer
2
  • Thanks. +1 for reference to temporal queries. If the users are simply using different combinations of criteria to see different results then I guess this is not a good fit for event sourcing. Do you agree with that? Commented Jul 31, 2018 at 19:41
  • @w0051977 Different combinations of criteria yielding different results is not unique to event sourcing. Any system can offer various projections of data. Commented Aug 7, 2018 at 14:49

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.