╔═══════════════════════════════════════════════════════════════╗
║ ║
║ ali fazeli · python backend engineer ║
║ ║
╚═══════════════════════════════════════════════════════════════╝
engineer = {
"name": "Ali Fazeli",
"role": "Python Backend Engineer",
"languages": ["Python", "SQL"],
"speaks": ["en_US", "fa_IR"],
"contact": "rabbitix98@gmail.com",
"focus": "FastAPI · Pydantic v2 · SQLAlchemy · Clean Architecture",
}I build maintainable, type-safe backend systems with a strong emphasis on clean separation of concerns and long-term sustainability. My projects are structured to scale — both in codebase complexity and team size.
| Layer | Tools |
|---|---|
| Framework | FastAPI · Django |
| ORM / DB | SQLAlchemy · SQL (PostgreSQL, SQLite) |
| Validation | Pydantic v2 · Python type system |
| Architecture | Clean Architecture · Domain-Driven Design |
| Infra | Docker · Git |
src/
├── configs/ # App configuration & env management
├── helpers/ # Shared utilities & exception handling
├── logics/ # Pure business logic — framework-agnostic
├── model/ # Domain models, DTOs, type definitions
├── repositories/ # Data access layer (adapters pattern)
└── services/ # Orchestration & use-case layer
Why this structure? Each layer has one reason to change. The domain logic never imports from FastAPI. Repositories are swappable. Tests are fast because they don't need a running server.
- Type safety first — if it's not typed, it's not done
- No magic — explicit over implicit, always
- Repository pattern — decouple persistence from logic
- Fail loudly early — validation at the boundary, not deep inside
- Write for the next engineer — including future-me
if a repo helped you, a ⭐ goes a long way