Need to know the difference between all of these patterns, and what are their origins.
All these patterns encapsulate requests into command objects.
In command objects that you see in hexagonal/DDD architectures, the command is just a POJO that the command handler takes as argument in the handle method.
Questions : what are the main benefits to not use "smart command" - with a execute() method - and go with simple "message command" instead (when the logic is inside the handler) ?
Thank you, I hope the question is not weird
edit:
https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91
The author talks about the reasons he uses this pattern
In the early days my implementation of the Command Pattern design consisted of classes that contained both properties to hold the data and an Execute() method that would start the operation. The design had an abstract Command base class that contained all of logic for handling transactions, re-executing commands after a deadlock occurred, measuring performance, security checks, etc. This base class was a big code smell and was a form of God Object with many responsibilities. Furthermore, having data and behavior interleaved made it very difficult to mock/abstract that logic during unit testing.
The same question has been asked in the comments, he answered :
I don't consider this the Command Pattern, although the patterns are clearly related, since they both deal with commands. But they are also very different, since the command pattern deals with a single ICommand interface that consumers can depend on. This allows them to know nothing about the commands they execute and it allows consumers to store, execute, and undo a list of unrelated commands. Take for instance a text processor or painting application where changes are made in lots of small steps and each step must be undoable. In such application it is pretty clear you need the command pattern. For Line of Business applications however, we often deal with transactions and need to add a lot of cross-cutting concerns around those transactions. This is a clear case for the pattern as I describe in in this blog post.
