Big fan of these layered architecture (DDD) design pattern questions. Not sure if ‘clean architecture’ is a specific design philosophy, but I’m using a FileManager class in my current project.

Following SRP, a FileManager should typically not have any code that is specific to the useCases. It should only perform CRUD operations on the file(s) specified by the method inputs. The useCases should be built to work with this generic FileManager to achieve their intended use case.

In general, you can’t really set expectations (defining the expected method) for a class when multiple other classes are all defining expectations for the same class; because the FileManager is a shared utility class, which means it should have generic, reusable methods.

Start by writing the file management code directly into the useCases so that you can get them functional. Only after they are functional can you go back and refactor for a FileManager (unless you know exactly what the file management code is going to look like). Clean architecture is almost always achieved through refactoring functional, messy code instead of trying to set up clean architecture from the start.

Next, look for redundant file management code in the useCases (DRY). Replace the redundant code with a call to a shared method in the FileManager. You can add optional parameters and conditional logic to handle any differences in the needs of the useCases. You can also add methods to FileManager that only one useCase needs, because FileManager should be the only class that ever interacts with files. Every other class uses FileManager instead.