Different Input Models for Different Use Cases

Same input model

We might be tempted to use the same input model for different use cases. Let’s consider the use cases “Register Account” and “Update Account Details”. Both will initially need almost the same input, namely some account details like a description of the account.

The difference is that the “Update Account Details” use case also needs the ID of the account to be able to update that specific account. And the “Register Account” use case might need the ID of the owner so that it can assign it to them. So if we share the same input model between both use cases, we’d have to allow a null account ID being passed into the “Update Account Details” use case and a null owner ID being passed into the “Register Account” use case.

Smelly code

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 logic into the use cases themselves, polluting our sacred business code with input validation concerns.

Exceptions