Different input models for different use cases
We might be tempted to use the same input model for different use cases. Let’s consider the Register account and Update account details use cases. Both will initially need almost the same input, namely some account details, such as a username and email address.
The Update use case will need the ID of the account that needs to be updated, however, while the Register use case does not. If both use cases use the same input model, we will always have to pass a null account ID into the Register use case. This is annoying at best, and detrimental at worst, because both use cases are coupled to evolve together now.
Allowing null as a valid state of a field in our immutable command object is a code smell by itself. But more importantly, how are we handling input validation now? Validation has to be different for the Register and Update use cases since one needs an ID and the other doesn’t. We’d have to build custom validation...
