Udi Dahan - If (domain logic) then CQRS, or Saga?

Domain-Driven Design Europe 2017
dddeurope.com - / ddd_eu
Organised by Aardling (aardling.eu/)
If (domain logic) then CQRS, or Saga?
The “if” statement - the guard clause that makes sure that what shouldn’t happen, can’t happen. We see it all over our code base, especially in our domain logic. The thing is, when we use properties of domain objects in those if-statements, we don’t even realize that other agents may have just changed that data - or will change it just a second later. In essence, hiding behind those little “ifs”, are all kinds of race conditions and collaborative domains - the places where CQRS approaches are necessary. Join Udi for a different perspective on domain logic, CQRS, and long-running processes. It will be quite a saga.
Udi Dahan is one of the world’s foremost experts on Service-Oriented Architecture and Domain-Driven Design and also the creator of NServiceBus, the most popular service bus for .NET.

[@EmanueleDiSaverio]

Udi is a great example of how having nice slides is absolutely NOT needed to be a great speaker :D

[@dmsanz_youtube]

great talk! About making commands almost never to fail.. I remember hearing from Greg Young something like "if a command does not fail and has to be accepted, maybe it's a fact (an event), not a command. Commands can be rejected"
Maybe Udi's statement on commands (almost) never failing, is something more motivated by the elegance of removing conditional statements in domain logic than driven by domain modeling.
I understand there are no strong statements here, specially out of context and maybe I misunderstood (please let me know if so). But if you design a system where commands almost never failed is because you've moved domain logic somewhere else. If you keep track of it, probably you see these validations (domain logic, after all) in the front end. Therefore, if that's the case, the commands happen way earlier, and this command that "almost" doesn't fail is, effectively, an event produced by a previous interaction.
With CQRS we can separate read model from write model, and we can't prevent users from sending a command that is not supposed to. But that's like assuming that all the commands will always be initialized by a UI (what if somebody decides to integrate with our API with a different UI that didn't take some validations retrictions and manage to send "forbidden" commands?)
Also, what about eventual consistency? If a command is motivated by what the user sees in the UI, maybe the command was driven by a stale state. That command would also fail.
Hopefully someone can clarify this.

[@trungthanhbp]

I think the statement "command can't fail" is talk about the business view not the technical view

[@alokbhardwaj2201]

I like your videos.
I understood the problem statement. Even I understood the domain specific constraint that needs to be applied. But I don’t understand how CQRS OR Saga help here.
In fact I don’t get any solution of the problem that you explained nicely.

[@titoluzuriaga8217]

The takeaway for impatients: 43:43 - 44:20

[@qdeqdeqdeqde]

set playback speed to 1.5x or more

[@jimifriis4507]

Thanks Udi!
A great talk, really pleasant to listen to your presentation!
See this, it gives you the tool/insight to next time think once more about if that if statement (pun intended) is actually trying to tell you something more important, a behavior hiding in your domain. Even though most of the things touch on here is something you do know this talk might highlight that knowledge for you, it did for me. =)

[@dmsanz_youtube]

I agree. It also helped me rethink some hidden business rules and long running processes behind a simple conditional.
I'm not so sure about the claim he makes to design commands to (almost) never fail though. That seems to me dangerously close to the concept of event, which actually tells me that there is "something" "somewhere" making some kind of validation beforehand to ensure the command that is send is likely to succeed. Maybe a user behind a UI with current or stale information?
So this video helped me answering one concern, but now I've got 10 more concerns :D

[@mehulbrahmvar5391]

Why the name Saga added in this video?

[@riccardoodone]

Long running process = Saga

[@andreujuanc]

Not true, Saga is a multiservice operation with compensation in case of a business rule violation. If I do Task.Delay(10000000) is this a Saga? Nope.

[@danielboris9031]

@@andreujuanc Long running process have nothing to do with "timing", but as requesting a transaction that goes across multiple bounded contexts.