81–90 of 90 posts
How strange, just today I've heard the Event Sourcing name and thought I don't know what it is. (Turns out it is this old idea I knew under various different names). And at the same day I hear about Event Sourcing on HN. What's the buzz?
I have been working with this sort of patterns for a while but I have yet to find good texts exploring the topic. Does anyone have book or paper recommendations for event sourcing? The stuff I have seen is mostly programmers reporting on something that worked on their particular domain. I am, looking for something more rigorous and comprehensive.
[1] https://groups.google.com/forum/#!forum/dddcqrs
[2] https://www.amazon.com/Enterprise-Integration-Patterns-Desig...
[3] https://www.amazon.com/Implementing-Domain-Driven-Design-Vau...
[4] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...
Earlier quoted context omitted.
> Imagine tooling that allowed an event stream to be used to create state for testing modules, crudlike helpers to allow crud-familiar developers to think that way at first, and workflows based on snapshots, rewind, etc. i know where you're going with this, and i honestly believe its a terrible idea (not to be discouraging or rude—just experienced.) if your event streams contain mostly CRUD (possibly ANY) then you're…
> if your event streams contain mostly CRUD (possibly ANY) then you're most likely applying it incorrectly. Its not just a version history of your data. The event type itself is data, which provides context and semantics over and above the notion of writes and deletes. Right. A good way to think about this is that as with rows in an RDBMS, events in an ES system are facts, and just as tables in an RDBMS define a cate…
Thank you for this, it has cleared many of my troubles with understanding event sourcing completely.
Here's the term I wish was unfashionable with the kids: reshaping. Did you spot all those command-to-query-to-event-to-log-to-storage data type conversions in those pretty diagrams? That's a whole bunch of needless reshaping of data as it flows through the system. For each one of those data transformations to be successful, there has to be accurate communications between people and bug free code written in the data c…
Open sourced ones? The largest example I'm aware of is https://github.com/MicrosoftArchive/cqrs-journey . There's a pretty extensive write-up of their experiences too. https://msdn.microsoft.com/en-us/library/jj554200.aspx
Earlier quoted context omitted.
> It's tempting to throw every new fancy technology at the problem when that is suddenly an option, but it's better to focus on the goal of splitting it apart only. Splitting it apart involves: (1) Dividing the data and functionality into a legacy component and a new-implementation component, (2) Making changes to the DB and application code for the legacy component, (3) Implementing the new-implementation component.…
"The hard part [...] is done in the analysis phase..." smells like big design up front that is usually more likely to fail than not, especially so for complex systems.
Earlier quoted context omitted.
I was thinking of making CRUD a specific event type that had meaning only in the context of changes to an instance of some schema. Of course, the most interesting events will not be CRUD oriented, but does this mean it's a mistake to include them at all, particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized?
> particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized? This is also an antipattern, btw—events between bounded contexts should be somewhat limited, and well-defined behaviors when doing so. What you're doing with a scheme like that, sharing CRUD events between external services or systems, breaks all kinds of conceptual and logical encapsulation (i…
Pattern matching? Creating useful state snapshots? Curious to hear more about your experience.
Earlier quoted context omitted.
> The CRUD one-row-per-pattern is common because it's enough for most projects. It works well with ORMs so you can build quickly and securely. If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable considering the value of data and the strategic leverage it can have today. Considering immutable facts tables are the mo…
> If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable You'd be surprised. For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this. I always find it strange when people use "unacc…
> This is unacceptable considering the value of data and the strategic leverage it can have today.
The last part is important.
Just because it's been true in the past, it doesn't mean this trend will continue. Maybe it keeps being true for your run-of-the-mill MVP, but I don't see it being acceptable for a system in any industry w/ any chance of making serious money in the mid-term.
Earlier quoted context omitted.
> If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable You'd be surprised. For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this. I always find it strange when people use "unacc…
The full sentence is: > This is unacceptable considering the value of data and the strategic leverage it can have today. The last part is important. Just because it's been true in the past, it doesn't mean this trend will continue. Maybe it keeps being true for your run-of-the-mill MVP, but I don't see it being acceptable for a system in any industry w/ any chance of making serious money in the mid-term.
Event sourcing is an extremely expensive design pattern to implement, and it's also very easy to get wrong. Implementing it tends to preclude junior developers from working on the project, makes it harder for database admins to understand the data, and it requires a lot of thought on how to structure the events.
So on a project with, say, a £20K budget, it might triple the cost. On a project that would take 4 weeks to implement with CRUD, it might take 3 months with event sourcing. You've got to justify that extra cost. It's better to let a BA decide what they will need, and by all means explain the pros and cons of different solutions.
But I don't for a second believe that every single project should now be using event sourcing instead of CRUD.
Earlier quoted context omitted.
> If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable You'd be surprised. For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this. I always find it strange when people use "unacc…
The full sentence is: > This is unacceptable considering the value of data and the strategic leverage it can have today. The last part is important. Just because it's been true in the past, it doesn't mean this trend will continue. Maybe it keeps being true for your run-of-the-mill MVP, but I don't see it being acceptable for a system in any industry w/ any chance of making serious money in the mid-term.
Again, you'd be surprised. Aside from advertising and consumer behavior analysis, there are not many industries that care or even have a need for such historical data.
The very idea that it must be necessarily valuable to store historical data about "all the things" (apart maybe from some aggregations you can create and store), seems more associated with the recent "big data" fad.
(I've seen 10-12 such trends rise and fall in the industry. In 10 years, I guarantee you it will have fallen off as a keyword, and only used as a technology where really appropriate).