Evidence · 01
How did you architect these systems, and why that way?
Same architect, two different layerings — because the constraints were different, not because of habit.
ConfirmHai
Routers → services → models, enforced as a contract
A multi-tenant web API with a growing route surface (37 and counting). This layering optimizes for request-lifecycle clarity: a router owns HTTP concerns, a service owns business logic, a model owns persistence — and shared files (models, schemas, config, main) are explicitly flagged as contract changes that need wider review before an AI-directed change touches them.
Client
tenant.html / owner.html
API layer
FastAPI routers
- 37 routes
Service layer
Business logic
Data layer
SQLAlchemy 2.0 (async)
Database
PostgreSQL (Neon)
- Render
BodhitAI
Strict Clean Architecture, dependencies point one way
An offline-first mobile app where the storage backend needed to be swappable and the reflection logic had to stay testable in isolation. Clean Architecture's dependency rule — outer layers depend inward, Domain depends on nothing — is what makes that swap possible without touching business rules.
UI layer
Presentation
- Blazor + MAUI
Adapters
Infrastructure
- Swappable storage
Orchestration
Application
Core
Domain
- No outward deps
The actual decision
Layering follows the deployment target, not preference
ConfirmHai's constraint is route-surface growth under one backend team of one — so the layering optimizes for how fast a new endpoint can be added safely. BodhitAI's constraint is an offline client where the storage layer might change under the app without warning — so the layering optimizes for isolation and testability of the domain logic. Neither is the "correct" architecture in the abstract; each is correct for what it was deployed against.