0

I'm on a project which often follows the trends, so whatever works for big cool companies, will surely work for us, regardless the contexts and specifics. If that sounds like a little rant, then it is.

This way, one of my team members jumped on implementing Event sourcing, calling it commit log. Which might be good, because the industry requires thorough auditing.

However, our project already stores everything as immutable, except the only property that changes on our entities is status (enums like CREATED / PROCESSING / COMPLETED). In other words, some events create the entities as a whole, and few other events change only their status.

The application is in PoC architectural state and it needs heavy refactoring, redesigning and remodeling.

The way how event sourcing is being implemented inflated the application code by about 15 %, and is present literally everywhere.

My question / request for oppinions (I assume that's ok on this site) is:

Do you think it makes sense to implement event sourcing on such system?

If you are familiar with events sourcing, you may know that it's quite a lot of effort to make it 100 % working, and future changes to the business logic / events model may get significantly complicated if we want to keep the old event records as the source of the current state.

Since the only thing that changes is the status, wouldn't it make more sense to record just the status changes, and otherwise store normal entities?

2 Answers 2

1

Whether it makes sense to implement event sourcing depends on whether it makes sense to implement event sourcing. It actually doesn't matter what the events are. What matters is that logging them is useful. If 99.99999% of events are "created object with the following properties," then that's what your log contains! If a bunch of "create object" events turn out not to be useful for anything, then ditch event sourcing all together!

Now, if I focus on the question in the last sentence, it looks like not only are they implementing event sourcing, but they're implementing a specific explicit form of it, where everything is store in an object with the name "Event" in its class-name. This could be inefficient, causing duplication. What you might do instead is keep a lightweight proxy Event that references the immutable object. If you want to see any details, you simply refer to the object itself.

It still may make sense to duplicate the effort in some situations. Sometimes you want the data stored in a different form, or with different properties. For example, you may want to have the event log stored in a linear buffer, with all of the data serialized.

But in the end, it all depends on the application. If event sourcing helps the application, then it helps. If it doesn't help, it doesn't help. The specific types of events are less important in that regard than what you do with the data. If you always throw it on the floor right after you log it, then maybe its time to stop following the trend! But there may be some advantages. Your coworkers may have better insight than we StackExchange citizens have.

0

our project already stores everything as immutable, except the only property that changes on our entities is status (enums like CREATED / PROCESSING / COMPLETED). In other words, some events create the entities as a whole, and few other events change only their status.

If I ran the zoo...

From your description here, it sounds as though your current design may be confusing two different ideas: the storage of immutable documents, and tracking the progress of instances of processes about those documents.

For storing immutable documents, I would expect a document store.

For tracking the progress; it can be reasonable to store progress as documents that describe the current state of the process instance, or by tracking the history of changes. The history can, of course, be used to produce current state on demand; but it is more powerful -- information persists even in the face of future changes.

The killer feature supported by history is temporal query -- you can recreate what the process instance looked like at any time in its history.

I'd argue that, if you don't business value out of temporal query, investing in an event sourced design is suspect (resume driven development?).

Now, it is true that most information systems can do interesting things with temporal query eventually, so it might be a good investment to implement persistent histories right away, even though you aren't sure how you are going to use them yet.

But there's a lot of challenge to justifying extra hoops to support temporal query of an immutable document.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.