Is it considered an anti-pattern to use nested static classes for service commands and responses?

I am structuring the command and response models for my service layer. Currently, putting all models into a single, flat folder (like /commands or /responses) is becoming hard to manage due to the sheer volume of files.

Since most commands and responses are specifically tailored to a single use case or service method, they are rarely reused across different services. I am considering using nested static classes inside the service class itself to encapsulate them tightly with the service they belong to.

For the few exceptions that do need sharing, I would extract them into a dedicated shared/commands folder.

Here is a simplified example in Java:

public class UserService { // Command public static class CreateUserCommand { public String username; public String password; } // Response public static class UserResponse { public String userId; public String status; } public UserResponse handle(CreateUserCommand command) { // Logic... return new UserResponse(); } }

**My questions are:**

Are there any hidden technical drawbacks or known anti-patterns with this approach

Does this approach negatively impact automated API documentation tools (like Swagger/OpenAPI) compared to using standalone classes?