A use case in a nutshell

First, let’s discuss what a use case actually does. Usually, it follows these steps:

1. Take the input.
2. Validate the business rules.
3. Manipulate the model state.
4. Return the output.

A use case takes input from an incoming adapter. You might wonder why I didn’t call the first step Validate input. The answer is that I believe use case code should only be concerned with domain logic and we shouldn’t pollute it with input validation. So, we’ll do input validation somewhere else, as we’ll see shortly.

The use case is, however, responsible for validating business rules. It shares this responsibility with the domain entities. We’ll discuss the distinction between input validation and business rule validation later in this chapter.

If the business rules were satisfied, the use case then manipulates the state of the model in one way or another, based on the input. Usually, it will change the state...