Use Cases

It’s time to implement the actual business logic that runs inside our application. Use cases are the places where this implementation happens, and they may or may not be directly linked to the external API of the system. The simplest use case we can create fetches all the rooms stored in the repository and returns them. In this first section, we won’t implement any filters to narrow our search. Instead, we’ll introduce code that utilizes filters in the next lesson, “Error Management in a Use Case,” where we’ll discuss error management.

Impact on our test case

Our repository is our storage component. Following the structure of clean architecture, this will be implemented into the external systems layer, which, as we mentioned earlier, is the outer layer. We’ll access this repository as an interface. In Python, this means that we’ll receive an object that we expect will expose a specific API. When testing, the best way to run code that accesses an interface is to mock the API. We’ve added this code to the tests/use_cases/test_room_list.py file.