If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this:

  app
  ├── controllers
  │   ├── task.py
  │   └── user.py
  ├── models
  │   ├── task.py
  │   └── user.py
  ├── repositories
  │   ├── task.py
  │   └── user.py
  └── schemas
      ├── extras
      │   ├── current_user.py
      │   ├── health.py
      │   └── token.py
      ├── requests
      │   ├── tasks.py
      │   └── users.py
      └── responses
          ├── tasks.py
          └── users.py

A structure around mini apps always turns out to be more beneficial for keeping boundaries intact in the long run:

  apps
  ├── tasks
  │   ├── controller.py
  │   ├── models.py
  │   ├── repository.py
  │   ├── schemas.py
  │   └── service.py
  └── users
      ├── controller.py
      ├── models.py
      ├── repository.py
      ├── schemas.py
      └── service.py

[0]: https://github.com/iam-abbas/FastAPI-Production-Boilerplate

The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.

Bogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers.

> Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum.

That's exactly where you shouldn't be using it! Relying on it as dogma will result in chaos.