Service Oriented Architecture: Commands & Events Explained!

[@coderider3022]

I’m sending to a queue for my request reply flows but my other commands are sent to a topic then I’m using filters to deliver the command via subject /label to the actual subscription which is linked to my code. I feel this way I can have an extra layer to flexibility and saves me coding queue names into anywhere. I have a topic per micro service domain and several subscriptions, all with their own filters. Happy to get comments on this.

[@jameshickey84]

Nice - awesome example at the end about concurrency issues and what to do. Just being aware of those kinds of issues is a huge thing.

[@coderanger75]

I enjoyed this video. Some of your latter points really emphasize that it is important for us as developers to put on our business hat. Being strategic and tactical is very much a learned skill.

[@CodeOpinion]

Yup. Understanding the business, the problem space, and solution space.

[@Hydrophish]

So glad I found this channel, tons of good stuff on EDA. Subbed!

[@CodeOpinion]

Thanks!

[@antoniocastrojunior684]

Keep up with the good work.

[@alirezafarokhi6738]

Hi Derek, thanks for making these video. would you please make a video about difference of "Service oriented architecture and Micro service architecture"

[@CodeOpinion]

Ya, good suggestion

[@eeevans]

I think the business understanding brought up by the question of commands failing is one of the hallmarks of being a senior developer. Understanding the Business Analyst role and how to work with it as a developer becomes uniquely important the closer you are to decision making. In some cases you have a BA you are working with and these question need to be raised and researched. In other cases, you as the developer are having to fulfill the BA role also and you need to be even more aware of such areas. Sometimes commands have to fail and you can't "oversell" as in the case of a bank withdrawal or similar value account. Or there is business logic around whether it can happen or not as in overdraft protection products, etc.

[@CodeOpinion]

Yup, all about validating assumptions. Often, business already has processes for handling consistency issues.

[@FrequencyModulator]

Great video, thak you for sharing! Btw, did you share the repo previously (and I missed it)?

[@CodeOpinion]

Code from the video is here: github.com/dcomartin/LooselyCoupledMonolith/tree/NServiceBus

[@FrequencyModulator]

@@CodeOpinion thanks a lot! That helps very much!

[@nikhilrathore2385]

Hi Derek. Thanks for the effort. I am coming from your event sourcing video and I have a question about command validation. Suppose we just store the events ProductCountIncreased and ProductCountDecreased. Now to store the current count, a projection would replay the events and get the result. But what what about command validation. Like if currently count is 10 then a decrease command of 15 will have to fail. But we are not storing the final state. So in this case would be need to replay the events for write as well? Been searching for a long for this question

[@CodeOpinion]

Yes, on the command side you replay the event stream to get to current state. You do it at runtime when processing the command. Projections, however, you do as events occur generally, so you aren't rebuilding at runtime for each query.

[@nikhilrathore2385]

@@CodeOpinion yes I understand the query db is populated asynchronously so reads won't be impacted. But the writes would be slower as event replaying is synchronous, is that right?

[@CodeOpinion]

Yes, you are reading the steam and replaying events to get to current state to process a command. How impactful that will be depends on the length of the stream and size of the events. Generally, not concerning

[@mikemccarthy9855]

"this command was going to fail anyhow"... "is over-selling even an issue"... "over-selling wasn't a Sales problem, it was a Purchasing problem..." I'd add that over-selling isn't a problem at all, over-selling is expected in this business domain and what you un-earthed through your analysis is an actual use case. Most developers spend WAY too much time focusing on the wrong problem, in this case "how can I prevent over-selling"? Not only is it impossible to prevent over-selling, but concentrating your efforts there is only going to lead to frustration and a lot of accidental complexity (plus, you're doing the business a disservice). You don't see airlines or hotels trying to prevent over-selling. What those domains do is offer compensating actions when over-selling occurs in terms of sending a guest to a competing hotel that does have a room for them or free-flight or money-based incentives for travelers for taking a later flight. These are business processes/use cases that often get overlooked by taking a "how can I completely prevent something from happening approach". If you take the "commands should not fail" approach, then all of the sudden, you open up a conversation with the business digging deeper into the domain and discover new uses cases that were hiding.

[@mikemccarthy9855]

Thinking even further through this, other compensating actions taken as a result of over-selling could be partial order fulfillments. Give the customer a choice. "We can get this item that is current out of stock for you by [est. shipping date] or you cancel this part of your order" (that has already been partially fulfilled). A "partial order cancellation" is possible under these circumstances. "Partial order cancelation" sounds like a use case to me. That's why thinking of a "order" in terms of mutual exclusion (either the order is fulfilled or cancelled) is a bad way to approach analysis, and most checks that try to prevent things from happening fall into this mutually exclusive way of thinking. To add a twist to this, in the concert/ticket sales domain, you have the same competition for limited resources like hotels and airlines do, but you can't have concert go-ers show up at a stadium with tickets only to tell them the "stadium is over-booked", here are some other concerts you may be interested in. So, in this domain, you cannot oversell... period. Using things like the Reservation Pattern (freecontent.manning.com/wp-content/uploads/reservation-pattern.pdf) during ticket purchase can prevent over-selling a stadium.

[@CodeOpinion]

Thanks for the comment and thoughts. As you said: "You open up a conversation with the business digging deeper into the domain and discover new uses cases that were hiding.". Exactly!

[@RasmusSchultz]

Instead of just returning without taking any action, the command could send an OutOfStock event? Maybe the order service cancels the order in response, while back office server notified someone to call a supplier and restock - and eventually, when the product comes back in stock, maybe the email service notifies the customer. As you said, yes, more domain exploration is required, so this is just an example of what they might come up with. But most likely, a command should never quietly fail without taking any sort of action, should it? At the bare minimum, some other part of the system needs to notify the customer that their order was rejected, so there needs to be an event for the appropriate service to know that we're out of stock, right? The system was asked to do something. If that fails, that's an event - it failed for a reason. Or not? 🙂

[@Bosslogq]

Hi Derek, thanks for making these videos. Great work. I have a question regarding events and commands after having a discussion with my work mates. In our system we receive a notification from 3rd party provider about a resource we created in their system earlier. This notification can indicate that something changed with that resource. To trigger a sync update on our side we could then either do SomethingChanged event or ChangeSomething command. But it is not really clear sometimes which to use... do you have any advice on that?

[@CodeOpinion]

Ya, very interesting example. When you receive their notification, you could invoke a command that is explicit that the change is because of that external system. Eg, ChangeThingyFromExternalData.

[@miletacekovic]

There certainly are business cases where commands can fail. In that cases, sort of CommandFailed event should be fired. But of course, as in your example, some command types (or most?) should be designed such that they cannot fail.

[@antoniocastrojunior684]

Hi Derek, I´ve been watching your videos about loosed coupled monolith and it´s really helpful, but I still remain with a bunch of doubts related to the authonomy of the boundaries. As far as I understood we should avoid making requests from the implementation of one boundary to the contracts of another to avoid dependencies. Sometimes it´s very hard to avoid it and I just can´t imagine a system without those dependencies. Could you clarify this?

[@CodeOpinion]

If you want autonomy then you won't rely on a synchronous request/response with other boundaries. If you have no expectation of ever splitting up boundaries into their own deployable unit, then you can do in-process calls to other boundaries at the expense of adding coupling via interfaces/delegates.

[@Cleannetcode]

Hello from Russia. Thanks for your video :)

[@idgafa]

Great video.

[@CodeOpinion]

Thanks for watching.

[@MJ46.91]

Or, there's the stupid option my company made. Take a rabbit mq and send "Request messages" having the schema of the whole process to be done - to the level of the result of each process between fail or success - and FORWARD "yes that's right, the message has the sequence of the services involved in a process where each service is going to use a chunk of that sequence- separated in dots " if you know what I mean 😉" to forward the message to the next service, and all of that happening with a consumer running in the route that published the request in the beginning "WAITING" and blocking the system waiting for the message with a response to be routed back to it, and then returning it to frontend. Yes sir, if I say command I get shot, if I say events, I get shot, if I say rpc, which is in a way what we're doing, I get shot, if I say CQRS also I get shot, If I say aggregate I get shot, if I say whatever, I get shot. Did we use the tool for our problem? No Did we shove the tool onto our problem? Yes, Did we complicate our life for nothing, you bet we did, And to add the cherry on top, we're doing it all in PHP, no frameworks what so ever, only php-amqplib. What do you think of that?!! Did we benefit from