Event-Driven Architecture lost its way 

Exactly 💯

The trend however seems more and more it's being used for data distribution.

​@@CodeOpinionevents are for communication, signalling - so using them for data transfer isn't wrong, but if people are just thinking of them like the outbox pattern, "row created", "row changed"... they're missing the internal role of events for interaction between components inside systems, rather than just for relay between systems

@@CodeOpinion I can see the problem though. Lets say we have a new event that does not match any of the event types we have now, so it isn't any of Order Received, Inventory Picked, Product Out of Stock, Order Shipped but something like inventory was taken by law enforcement as evidence of a crime. Now how do we fit this? Do we create a new event type for this rare event type? It is possible this inventory that we deducted would come back later and we have to increment it again. Do we create a new event for that?

​@@etexasWhat's stopping you on creating that new event?

"prepare for deallocation" ;-)

Agree'd it's a fundamental problem of "jira ticket resolver". But we as an industry enable it by thinking of ourselves as a tool specific developers. Eg, I'm a React Developer.

​@@CodeOpinion I was reading some comments and on this topic, I actually want to brag about an inhouse project i'm developing at my company. It's a SPA-like application made 100% with HTMX. I was mostly a backend dev and most of my frontend experience was in React. HyperMedia was a little mind bending with a traditional (non-nestable) router but it's working out quite nicely. I actually never have to worry about state management and consistency since the database people have already solved that for me :D

I see that OOP problem, when I do a job interview, there's 1 of 10 can explain OOP in a meaningful way. Some candidates take classes as groups of functions.

This is easily solved by defining the processess in their own domain (e.g. as bpmn process description) and infering business events from the state changes of instances of that flow. No need to do it the other way round (i.e. infering the process from events) as long as the event names from the process state transitions are unique.

The biggest is DEVOPS. It as never supposed to be a role in an organization / department. It was supposed to be a collaborative process between DEVelopers and OPerations to facilitate faster deployments. Now look at what it became.

Maybe the level of abstraction and DDD were not the right tool for the actual problem in the first place? DDD is not needed for simple CRUD like processes, its in fact overkill. You don't need a lot extendibility and flexibility? Fine, don't over-engineer and don't abstract too much. When I started I thought that DDD is a great idea for everything, but in fact, it is not, as every tool. Especially in architecture every concept has pros and cons, it's like a scale that must match the combination of pros and cons of the chosen solution to the actual requirements. You will *always* give something up for something else. The question is just if that trade off actually satisfies your requirements, functional and non-functional. And architecture evolves, do YAGNI/KISS, today CRUD might he better than CQRS, 3 years later, the project and company grew, new requirements appear, reevaluate and CQRS/DDD *might* be a good choice by now.

Glad you watched till the end. Often time it is for reporting and UI composition type purposes rather than needing data to enforce business rules.

Why do you need multiple services if they share the same data? Or why does one service need all data of the other service? As mentioned in the video, this couples one service to the Schema of the other service, and doesn’t fulfill one of the main benefits of event driven architecture: decoupling

@@pianochess1882 No it doesn't, because the schema of the entity that is included in the event can be different from the schema that the owning service uses internally. Consumers are _always_ coupled to the event schema. The important thing is that this schema can be evolved independently. There are many cases where one service needs data from another. For example in an e-commerce system there will be dozens of different recommendations that all ultimately need to know what products there are to sell.

Ya it could be an afterthought, as well as a "I need data from this service and we want to use EDA". The data distribution part is what is going to cause the coupling even if its not temporal via EDA.

Good point, and this failure is seen in a broader set of APIs, RESTful too can be slapped on existing services within consideration of consumers of the interface. Leading to lipstick API led architecture, which is just spaghetti integration over API.

Happy to help!

The warehouse complexity sure does not need to be exposed to the shop. In DDD, you speak about domain translation when you cross boundaries. The shop should have a translation component that translates the events emitted by the warehouse domain to "simplified" events for the shop.

@@Fred-yq3fs"The shop should have a translation component that translates the events emitted by the warehouse domain to "simplified" events for the shop." Eh, what???

I do understand what you are saying. But I agree with the point of the video, have a ItemInventoryChanged event with an iD, previous, current, and quantityChanged. Instead of just a ProductIpdated event with all properties of the entity

A service can produce multiple events, ie ProducrtSold as well as InventoryChanged, and different consumers can react. That’s why DDD must be looked at as a whole and not just isolated to one domain. Each domain should at least know the best way to publish any updates that are happening in it

It could be, but depending on how your navigating it. They know the workflow, so in that sense yes, but I favor hypermedia and then the client doesn't know where they are sending a request.

Ultimately it comes down to whether the organisation one works in, has reached a certain scale and complexity that a single shared database is becoming a problem (data ownership enforcement, conceptual integrity of the domain model, performance and load, traceability etc). The problem usually is not the tech its how the organisation is designed and how it communicates amongst its various departments. Good boundaries in the organisation design should lead to good modularity in software, then whether to have those modules split up in async/sync services running in their own processes, is a decision you can defer until you need it. If you don't have a problem that a solution solves, don't use that solution no matter how cool or shiny. Don't try to invent a problem to justify using a solution.

@@cybernetic100 Yes that makes a lot of sense. And often, I’m have been the only developer or the team has been very small and responsible for the whole system.

I don't like duplicated data, but you don't necessarily need to duplicate data. For example, I work on a SAAS product where basically everything needs to know about tenants, so we have a tenant database, and we have a service in front of that database. We don't force every service to have a copy of the tenant data. Other services have their own data, and that includes a tenant id, but if they want to know something about the tenant they need to ask the service. Nothing needs to know everything about a tenant though, so there is no "get whole tenant entity" endpoint. The main advantage I've found is that you can change how data is stored and deploy one service, rather than having to redeploy several services when things change. We previously had a shared database for rules, the UI would write to it, and 3 other services would read the rules and evaluate them. Every time we added a new type of rule we needed to redeploy 4 services together. We put a rules service in front, which has a crud API for the UI and an RPC API for rules evaluation, and now changes to rules only affect that service. We use a mix of crud/domain/RPC/commands/events where appropriate. For example when a tenant is deleted we need to raise an event so that other services delete everything related to that tenant, for GDPR.

I believe in "the simpler the better" approach. I see benefits of splitting a monolith into microservices only when you assign different teams (owners) to each of the microservices, so you decouple not only the code, but the release schedule, the coding pace. It comes with a cost of contracts sharing and maintenance. Sometimes I see attempts to split solutions to microservices within a single team in the initial phase with no actual ownership splitting. This brings more complexity with no benefits at all.

Why did a crud operation affect 20 data points? Why was this operation performed? Did a user just go „I’m just randomly gonna update 20 properties“. This usually doesn’t happen, so what was their intention?

What I find good about CRUD, is that people can make changes all over the entity on the client side. Double check if everything is okay, then push Save. With commands, this workflow is not possible. All kinds of modal dialogs, popping up, when confirming they push data onto the server. No way to be unsatisfied with the modification of the data, and revert to the initial entity state.

@@dragomirivanov7342 And what i don't like about CRUD, is that people can make changes all over the entity on the client side :) Jokes aside, i think CRUD makes a lot of sense with forms. But when you want to push it a little further, it becomes pretty complex to understand the intent behind a generic PUT. As soon as you have a couple business rules, you should start expanding your CRUD into a CRUD-ish where some general attributes can be set via CRUD but actions have their own end-points At least that's what i think makes more sense to me but it's hard sometimes especially if you allowed editing an attribute via CRUD and now you want to revoke that ability..

Great comment. As with anything, there is no perfect solution imo. Maybe ProductUpdated with a before and after as well as array of modified properties? So a consumer that cares about price changes could say if (eventDetails.changedFields.includes(“price”) // do something if price is lower if (eventDetails.previous.price > eventDetails.current.price)

@@kevinclark1783 This is what I do. `reflect.DeepEqual(old.field,new.field)` and then decide what the command should have been. However supplying `$intent` field in the entity should supply another hint.

Absolutely agree, so we might be misunderstanding. Events can carry data beyond identifiers, just as your example of purchase order rescheduled. What i'm more referring to is CRUD over entity driven data changes to propagate data to other services and lack any type of business meaning. As you said the event carries enough business meaning. ProductUpdated isn't mean anything.

Thanks!

Yes, UI or ViewModel Composition is a challenge: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ILbjKR1FXoc.html

The reality is you really can't. You'll likely need a denormalized projection of all the upstream systems. Old school RDBMS still drives business thinking.

Compose the data from disparate sources as you need to. It could be on demand to the various boundaries or you may have the data already composed. If you're handling the initial event async, then you have a lot more options in terms of failures if you need to sync request/response calls to other boundaries to get that data.

Often those types of details are metadata of the message. Often you can think of the event itself have an envelope that contains that data.

@@CodeOpinion And why not make this metadata part of the message, i.e. simply include the full entity in addition to the event. Metadata (headers in Kafka for example) is not as well supported by tooling.

I agree with metadata, Event { type:string, details: object with information needed for that event, metadata: object with anything else you want for logging, debugging }. But if the consumer does something based on a user detail, then imo the user should be part of the “details” because at that point it is not only used for informational purposes

@@kevinclark1783 Meta data sounds like a good solution but where does this meta data get's filled. Currently I've implemented (php/symfony) it by sending the users id and current timestamp to the behavioral methods on my domain model. But this causes a lot of duplicate / boilerplate code. Would you inject some sort event factory to your model which includes this meta data or pass it to the method in a 'meta' value object?

Really? ha, I usually think it needs to be improved. Just a blue yeti that's hanging forward/above the camera

Then let it be CRUD and don't publish an event.

Never mind. I did see your other video and answer was projections

I think it's been fixed since newer videos.

I had a comment about this about my last video. I don't notice it, but not to say you're wrong. Is it the entire video or somewhere specific?

@@CodeOpinion I noticed it immediately. It seems to be the whole video

Trying to sort out the sync. Someone else mentioned it.. unfortunately, I'm not noticing it but I'll try and sort it out.

@@CodeOpinion I noticed it as well. Video seems to lag behind audio, it's pretty distracting. I had to stop watching the video and just listen to the audio so I could focus on the content, which was great by the way!

Thanks for the comment and glad you hung on to see where I was going with it. Maybe I should cut to the chase quicker?

Correct

This approach also solves the problem that usually occurs for people is that. You have multiple consumers of the events and everything need to have different data by handling the event in memory and having a handler for that that actually invokes a command to said service, which you can do with transactional outbox, you now know exactly what data is needed for that command.

It goes the same for example Shipping service. When you place an order, you could call /ship in the order service and know exactly what information is needed for shipping to ship this. In real world. When a customer orders something from a store and asks this to be shipped and there is no IT systems. The peope from the store would go to post office for example and tell them to ship that. Issuing a command basically.

From one of your other videos. You publish the OrderPlaced event, have an handler for that, that uses MediatRHangfireBridge to invoke a ShipRequest and have a ShipRequestHander in background process that has an handler for it. You can also choose which data to incorporate in the ShipRequest when creating in, data that you already have in memory for example and you could also fetch some other data in the ShipRequest handler later that is needed to invoke the actualy shipping service.

I never suggested having the same event be named multiple different ways. Data centric events can be useful in query/reporting purposes when you need to compose disparate data. That's very different than needing data for another service and you expect consistency because you need to enforce business rules. We clearly have a different view of what services are. Processing power and how you physically deploy a logical boundary is limitless. That doesn't make them separate "microservices". Hard disagree with "one of the main reasons for microservices". That notion is one of the main reasons why so many systems are in a coupling nightmare and can't make sense of microservices.

@@CodeOpinion Again, disagree with most of your comment. Indeed we have different views on what is a microservice and what good architecture/software engineering practices are. Perhaps my view on this is skewed from my experience with high load, low latency systems. Agree to disagree.

Agreed, the interpretation and how it's used has changed.

@@CodeOpinion more like abused than used 😉 that’s why it’s crucial that you have solution architect that knows what event driven architecture actually is and what it isn’t.

Thanks for the comment, I guess?