Don't Let the Internet Dupe You, that's NOT Event Sourcing

[@MerrionGT6]

Yes - This is key - the "event" is a business defined thing, not a technology concern.

[@marna_li]

Software Developers often jump directly to implementation details. Treating a framework as synonymous with the pattern. Essentially, confusing both architecture and design with the technical details. Events make such better sense when you see your system as a set of components/services that interact through them. Domain-driven design FTW.

[@Greenthum6]

Excellent video. There is a lot of misinformation around event sourcing. It is a difficult topic and can be misunderstood easily. The main concept is pretty clear, but I started to really learn it a bit after coding one simple one myself. Now I can go back to see those Greg Young videos again and listen what the hell he was talking about.

[@MsTArray]

underrated! thanks for the explanation

[@CodeOpinion]

Glad it was helpful!

[@Jason_Shave]

Agree with everything here. The one comment I'd have is to evaluate frameworks where you can and where they add value. Depending on your situation, such as whether or not to write your own messaging library on top of an SDK, largely depends on factors such as company policy, access to public libraries, contractual obligations made to other customers (i.e. GDPR, Redaction, Encryption). Like everything in life, it's difficult to say "you should always...". Having recently written a library on top of an SDK for messaging, yes we had to write a lot of code to get the features we wanted, but that decision was in part made as a team and in part due to the company's policy/etc. The upside is that we have something we know and can support/maintain and share with others on the inside. I think the message here (no pun intended) is that you leverage what you can, learn from others, and build/learn something along the way in an efficient manner. Thanks for setting the record straight once again :)

[@CodeOpinion]

Agree. I'll start saying "in the vast majority of cases, ymmv" 😂

[@brandonpearman9218]

Agreed that there is a clear difference between ES and EDA but I think in >90% of practical situations teams see them as the same because they are done together. ie An event for communication gets consumed to create state. Video is good to help people understand the difference. I think changes to your events is a valid concern though and I would suggest to not use ES until your system has more stable business concepts. I just finished a project where business changed their minds every few weeks and our "stable" business concepts turned out to not be so stable lol.

[@CodeOpinion]

Versioning events can be a challenge regardless of Event Sourcing or EDA because you have to deal with the consumers. With ES, the consumer is it's own boundary, which at least you have control over. Regardless, versioning can be challenging.

[@health_doc]

Good video. Wish it was longer ;)

[@jameshickey84]

Good job. Keeping it crud'y.

[@CodeOpinion]

ha! Thanks James!

[@srieen100]

Well explained. Keep rocking!

[@CodeOpinion]

Thanks, will do!

[@invalidred]

What are some good messaging libraries for Node.JS, Java and Rust?

[@nalcow]

great content !

[@CodeOpinion]

Thanks!

[@sukantagarwal]

5:40, can you let us know few examples of these libraries.

[@CodeOpinion]

In the .NET Space: NServiceBus, MassTransit, Brighter.

[@MrBa143]

I can recommend Brighter. Super easy to get up and running with a few lines of code, especially using their V9 which is currently in pre-release, and then you can slowly learn and configure it along the way.

[@brettmiller6955]

Great video! What I'm not clear about, is how to ensure that a new service boundary, that wants to provision its state from the events it receives, would do that if it doesn't have access to the event log?

[@CodeOpinion]

Another service boundary has it's own state. It isn't deriving it from another boundary. It may use other data from another boundary as a reference, but it should own it's own state. This video on data consistency might be helpful: kzbin.info/www/bejne/q3y4g6N7ZpeAndE

[@devbyjesus4176]

There is a good book to learn about that ?

[@michelsafi1021]

Hey I have a question. How can I use entity framework core with clean architecture? I define an interface for my repository in my service layer. The implementation using entity framework is defined in the infrastructure layer. The thing is that entity framework related functionality seems to always slip into my service layer like Include or AsNoTracking. I hope you can answer me or post a video about this if it is worth it. Thank you, you videos have been a great help for me in my path as a software architect.

[@Coburah]

Define your own abstraction. Take a look at some structural design patterns: Proxy pattern or Facade pattern

[@jonaslomholdt]

If I have events from multiple sources and the domain consists of data from both, what would be a good way to handle that? Any particular pattern, or would the domain just be modeled to handle partial updates?

[@CodeOpinion]

Not entirely sure what you mean? Defining an aggregate (event stream) in some ways can be defined by the business logic required to validate commands. If you haven't already check out this video: kzbin.info/www/bejne/eWa3nn-Dj5mZjtE

[@RM-bg5cd]

Hi Derek, great video as always. Are there any Event Sourcing books that you would recommend reading?

[@CodeOpinion]

Greg Young's ebook on event versioning is helpful: leanpub.com/esversioning

[@RM-bg5cd]

@@CodeOpinion thank you!

[@bobbycrosby9765]

Event sourcing seems like a good fit for data you need a historical view on, or would that be somewhat orthogonal in such a system? An example that comes to mind from things I've worked on is an ecommerce platform. Orders would display a history of things that happened on them (created, charged, shipped, refunded, etc). Similarly, reporting on that ecommerce platform had to work in specific ways, where we had to be able to effectively rewind history and look at data within specific periods of time.

[@CodeOpinion]

It's not just historical view, it's WHY the state transition occurred. For example, you could append to a table/collection the same aggregate/entity over and over and just assume the last one is the current version. You'd get historically all the changes implied by the differences, however you wouldn't know WHY. Events describe the transition but the name of the event describes the WHY.

[@croncoder862]

Where do people get such confidence to write crap and present it so well ?

[@CodeOpinion]

I don't think anyone intends to mislead or provide bad information. I think our industry is full having to parse what's good and bad info unfortunately. That can be very challenging when learning something new. What's the correct blog/video? Whos right? Unfortunately with Event Sourcing, there's a lot that are very similar to this post which just simply conflates events for state AND events for communication. I almost always see this when in reference to Kafka.

[@frankenbeans6930]

The name of this channel is literally 'CodeOpinion' which tells you what you need to know.

[@adambickford8720]

I agree w/you but IME using 'event sourcing' as an implementation detail for a bounded context isn't what most people even want. Most would just use an RDBMS w/an 'audit trail' of some kind. I think they are imaging a full CQRS like 'system archetecture', which likely isn't what they REALLY want/need either, it just seems sexy.

[@CodeOpinion]

I don't disagree that there are a lot of applications/services/systems built are using the wrong approach. But I don't think that's specific ES or CQRS. I also think the reverse is true where there are applications/services/systems built focusing on CRUD when they shouldn't be. I talked about that in this video "CRUD API + Complexity = Death by a 1000 Papercuts" kzbin.info/www/bejne/oZLPdWuKmLd1ecU

[@beam_campus]

Thank you for this video, we really appreciate your channel and like your content. However, this time, some things you claim don't really resonate. You say at 0:17 that "Event Sourcing is using events as state, while event driven architecture is using events to communicate with other service boundaries". That is not entirely accurate. In event sourcing, the event stream is an (infinite) stream of immutable FACTS, from which ANY state can be projected (which is what the whole premise of CQRS is about). True, the command (write) service has its own model, and for each command that is send to the write service, a specific state is generated by applying committed events to the aggregate, before the command execution is attempted, but the facts (events) as such do not carry state, rather state transition payloads. One of the more important aspect of ES is precisely that state is transient, temporal. I think that the confusion comes from the fact that people usually name Event Notification, Event State Transfer and Event Sourcing in one breath (thank you, mr Fowler); while they are totally different beasts. I would much rather make the distinction along the lines of imperative system design vs reactive system design (i don't mean reactive programming!). Event Notification, Event Carried State Transfer and Explicit Command Execution (be it synchronous via REST and what not or asynchronous via message brokers) fall under imperative systems design, because for these 3, the system as a whole relies on the hope that messages are successfully processed, in order to keep the global (mutable) system state consistent. Which leaves ES as a manifestation of reactive system design, because state and command attempts occur as a reaction to a stream of well established facts. All this boils down to the choice between mutable (where state is persisted, continuously updated -in other words destroyed and thus, always 'current') and immutable architectures (where state is derived from an ordered, historical stream of facts and thus, 'temporal'). Mutable architectures are in essence built around data-driven services, and the always-current system state relies heavily on the messaging patterns that you name in this video, in order to guarantee consistency in the face of behavior (=business value). No matter how well crafted these services may be and no matter how 'individually deployable' they may be, in case of network partitioning, the best course of action is to bring the whole system down, because 'in flight' messages may become meaningless in terms of system consistency when the broken service comes back online. Services in immutable architectures are behavior-driven, consider behavior as part of their bounded context and act as guardians of a process, instead of state. When one breaks down, the rest of the system remains available. We could talk for hours about this over a fine Polish beer, I am sure :) By the way, I can recommend "The Art of Immutable Architecture" by Michael Perry and "Strategic Monoliths and Microservices" by Vernon Vaughn as presents under the Christmas tree. Happy Holidays! Peace and keep up the good work!

[@CodeOpinion]

Thanks for the comment. I've created another video about "What do you mean by Event?" which talks about the differences between ES events, Event Carried State Transfer, and Events as notifications for workflow. kzbin.info/www/bejne/p3ynY4yLia90jq8

[@frankenbeans6930]

Good presentation and good work demystifying some of these concepts. Is it just me or does event sourcing have some of the most pretentious terminology? Projections? Give me a break.

[@CodeOpinion]

I'd prefer Read Model but that's what most call it in that space.

[@strandedinthe0737]

awesome

[@alirezaasadi8656]

nice

[@marna_li]

Software developers like to complicate things. I have seen this a lot, when software developers talk about some new pattern they always make it a much bigger thing by talking implementation - stuff that has nothing to do with the pattern itself. Often implementing something based on a template, without questioning it: like with Clean Architecture. Essentially, misunderstanding what a template (opinionated implementation) vs a pattern (a set of principles) is. When it comes to design, software developers often seem to care more about specific technologies, like talking AWS when it, in reality, is just an implementation detail. "Oh! A new framework! Everyone else is using it. So should we! And now we are doing X" Just keep to the core principles: Just because you create a lot of small services and use a particular service bus, that does not show that you know micro services. And just because you have "events" - being "event-driven", it doesn't mean you use Event Sourcing.