Yes - This is key - the "event" is a business defined thing, not a technology concern.
@marna_li2 жыл бұрын
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.
@Greenthum62 жыл бұрын
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.
@brandonpearman92182 жыл бұрын
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.
@CodeOpinion2 жыл бұрын
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.
@Jason_Shave2 жыл бұрын
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 :)
@CodeOpinion2 жыл бұрын
Agree. I'll start saying "in the vast majority of cases, ymmv" 😂
@jameshickey842 жыл бұрын
Good job. Keeping it crud'y.
@CodeOpinion2 жыл бұрын
ha! Thanks James!
@MsTArray2 жыл бұрын
underrated! thanks for the explanation
@CodeOpinion2 жыл бұрын
Glad it was helpful!
@AssFaceNFT2 жыл бұрын
Thought I was getting muddled! 🙏🌹
@health_doc Жыл бұрын
Good video. Wish it was longer ;)
@srieen1002 жыл бұрын
Well explained. Keep rocking!
@CodeOpinion2 жыл бұрын
Thanks, will do!
@invalidred Жыл бұрын
What are some good messaging libraries for Node.JS, Java and Rust?
@nalcow Жыл бұрын
great content !
@CodeOpinion Жыл бұрын
Thanks!
@brettmiller69552 жыл бұрын
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?
@CodeOpinion2 жыл бұрын
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
@croncoder8622 жыл бұрын
Where do people get such confidence to write crap and present it so well ?
@CodeOpinion2 жыл бұрын
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.
@sukantagarwal2 жыл бұрын
5:40, can you let us know few examples of these libraries.
@CodeOpinion2 жыл бұрын
In the .NET Space: NServiceBus, MassTransit, Brighter.
@MrBa1432 жыл бұрын
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.
@adambickford87202 жыл бұрын
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.
@CodeOpinion2 жыл бұрын
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_campus2 жыл бұрын
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!
@CodeOpinion2 жыл бұрын
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.
@RM-bg5cd2 жыл бұрын
Hi Derek, great video as always. Are there any Event Sourcing books that you would recommend reading?
@CodeOpinion2 жыл бұрын
Greg Young's ebook on event versioning is helpful: leanpub.com/esversioning
@RM-bg5cd2 жыл бұрын
@@CodeOpinion thank you!
@michelsafi10212 жыл бұрын
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.
@Coburah2 жыл бұрын
Define your own abstraction. Take a look at some structural design patterns: Proxy pattern or Facade pattern
@jonaslomholdt2 жыл бұрын
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?
@CodeOpinion2 жыл бұрын
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
@bobbycrosby97652 жыл бұрын
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.
@CodeOpinion2 жыл бұрын
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.
@marna_li2 жыл бұрын
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.