mirror of
https://github.com/leonardomso/rust-skills.git
synced 2026-09-14 19:33:21 +08:00
0016d5cfb2
Includes rules for: - Ownership and borrowing patterns - Error handling with thiserror/anyhow - Memory management and allocation - API design following Rust guidelines - Async/Tokio patterns - Performance optimization - Naming conventions - Type safety - Testing strategies - Documentation standards - Project structure - Linting configuration - Common anti-patterns to avoid
3.3 KiB
3.3 KiB
proj-mod-by-feature
Organize modules by feature, not type
Why It Matters
Feature-based organization keeps related code together, making navigation intuitive and changes localized. Type-based organization (all handlers in one folder, all models in another) scatters related code across the codebase, making features harder to understand and modify.
Bad
src/
├── controllers/
│ ├── user_controller.rs
│ ├── order_controller.rs
│ └── product_controller.rs
├── models/
│ ├── user.rs
│ ├── order.rs
│ └── product.rs
├── services/
│ ├── user_service.rs
│ ├── order_service.rs
│ └── product_service.rs
└── repositories/
├── user_repository.rs
├── order_repository.rs
└── product_repository.rs
Good
src/
├── user/
│ ├── mod.rs # Re-exports public items
│ ├── model.rs # User struct, types
│ ├── repository.rs # Database operations
│ ├── service.rs # Business logic
│ └── handler.rs # HTTP handlers
├── order/
│ ├── mod.rs
│ ├── model.rs
│ ├── repository.rs
│ ├── service.rs
│ └── handler.rs
├── product/
│ ├── mod.rs
│ ├── model.rs
│ ├── repository.rs
│ └── handler.rs
└── lib.rs
Benefits
| Aspect | Type-Based | Feature-Based |
|---|---|---|
| Finding code | Search across folders | One folder per feature |
| Adding feature | Touch 4+ folders | Create one folder |
| Understanding feature | Jump between folders | Everything in one place |
| Deleting feature | Hunt through codebase | Delete one folder |
| Code ownership | Unclear | Clear feature owners |
Module Structure
// src/user/mod.rs
mod model;
mod repository;
mod service;
mod handler;
// Re-export public API
pub use model::{User, UserId, CreateUserRequest};
pub use handler::router;
pub(crate) use service::UserService;
Shared Code
src/
├── user/
├── order/
├── shared/ # Cross-cutting concerns
│ ├── mod.rs
│ ├── database.rs # Connection pool
│ ├── error.rs # Common error types
│ └── middleware.rs # Auth, logging
└── lib.rs
When to Flatten
Small modules don't need deep nesting:
src/
├── user/
│ ├── mod.rs # Contains User struct + simple functions
│ └── repository.rs # Only if complex enough
├── config.rs # Simple enough for single file
└── lib.rs
Hybrid Approach
For larger features, nest further by concern:
src/
├── billing/
│ ├── mod.rs
│ ├── invoice/
│ │ ├── mod.rs
│ │ ├── model.rs
│ │ └── service.rs
│ ├── payment/
│ │ ├── mod.rs
│ │ ├── model.rs
│ │ └── processor.rs
│ └── shared.rs
See Also
- proj-flat-small - Keep small projects flat
- proj-pub-use-reexport - Clean public API
- proj-lib-main-split - Lib/main separation