The best project organizational structure

[jerry-rs]

.
├── Cargo.lock
├── Cargo.toml
└── src
    ├── config.rs
    ├── db
    │   └── mod.rs
    ├── domain
    │   ├── auth
    │   │   ├── dto.rs
    │   │   ├── handler.rs
    │   │   ├── mod.rs
    │   │   ├── repo.rs
    │   │   ├── router.rs
    │   │   └── svc.rs
    │   ├── mod.rs
    │   ├── site
    │   │   ├── dto.rs
    │   │   ├── handler.rs
    │   │   ├── mod.rs
    │   │   ├── repo.rs
    │   │   ├── router.rs
    │   │   └── svc.rs
    │   └── user
    │       ├── dto.rs
    │       ├── handler.rs
    │       ├── mod.rs
    │       ├── repo.rs
    │       ├── router.rs
    │       └── svc.rs
    ├── main.rs
    ├── migrations
    ├── models
    │   ├── auth.rs
    │   ├── mod.rs
    │   ├── site.rs
    │   └── user.rs
    ├── routers.rs
    └── state.rs

9 directories, 30 files

[tomnekic]

Thanks. I can see the advantage of this layout: each feature has a predictable local structure.
One thing I’m trying to think through is how this would handle the non-HTTP parts of the backend.
We have here API routes, background workers, monitoring checks, incident detection, notification delivery, metrics, permissions, and database repositories. In a domain/{feature}/{dto,handler,router,svc,repo} layout, where would you put logic that is not really route-specific, such as monitor execution, notification dispatch, rate limiting, metrics, and worker orchestration?
Would you keep those as separate top-level modules, or would you still fold them into the nearest feature folder?

[jerry-rs]

If it's a specific feature, place it in domain/{feature}/{svc}

[tomnekic]

That makes sense for feature-specific business logic. If I applied this structure blindly, cross-feature runtime logic could get forced into the nearest feature service. My main question is where this structure draws the line between feature-local business logic and cross-feature/runtime application logic.

[tomnekic]

I moved this to Discussions because this is an architectural direction proposal rather than a confirmed bug or scoped implementation issue.