I was just hoping someone might be able to answer a few questions I have regarding the proper design of DTOs and Domain Models. I'm currently working on a project which involves leveraging a SOAP API.
Since we're working with SOAP we have the added benefit of generating a number of objects (DTOs) using the provided WSDL file. I've also subsequently built a number of commands which are allowing us to better encapsulate the intent of each request and simplify our interface to the API.
Each command handler has an associated "command" object which stores all of the necessary data to complete the request successfully.
I actually have three questions regarding this approach:
1) Is it unusual to call command handlers directly, thereby replacing the Command Bus as our invoker. Obviously we would lose the ability (at least in these select instances) to pass our commands into a queuing application which would allow us to execute the command in a non-sequential order.
However, I have identified some cases where we would actually need to parse the API response data on runtime. Could this be construed as a potential issue in the design of our application?
2) We're currently performing validation on the request data before passing it into our immutable command objects. However, there may be some cases where we need parse data from the DB/CLI prior to initializing our commands.
As a result, I've considered placing our validation logic into the command objects themselves. If validation fails then a exception might be thrown. Does this seem like a reasonable approach or am I again violating some design principles?
3) This may sound foolish but what exactly is the difference between a Domain Object and a DTO. I've heard the command objects themselves being referred to as a DTO yet they appear to belong to the domain layer (unless I'm mistaken).
Could the command object be more accurately described as a DTO or a Domain Model?
Thanks again. I do appreciate the feedback.