A Use Case in a Nutshell

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

1. Takes input
2. Validates business rules
3. Manipulates the model state
4. Returns output

A use case takes input from an incoming adapter. You might wonder why I didn't call this step "Validate input." The answer is that I believe use case code should care about the domain logic and we shouldn't pollute it with input validation. So, we will do input validation somewhere else, as we will see shortly.

The use case is, however, responsible for validating business rules. It shares this responsibility with the domain entities. We will 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 of a domain object and pass this new state to a port implemented...