Project Structure
Read docs/project_structure.md for the full module layout documentation before answering questions about where code belongs or how modules are organized.
Quick reference
Application entry points
| Module | Platform |
|---|---|
:composeApp | Desktop (jvm), Web (js, wasmJs) |
:androidApp | Android |
:iosApp | iOS |
:server:impl | Backend (Ktor) |
Feature modules (feat/<feature>/)
Each feature follows hexagonal architecture with these layers:
- •
business/— Platform-agnostic domain models. Innermost core. Only depends on:lib:core. - •
be/— Backend:app/(use cases) >ports/(interfaces) >driven/(DB implementations) +driving/(HTTP routes) - •
fe/— Frontend:app/(use cases) >ports/(interfaces) >driven/(HTTP/SQLite implementations) +driving/(Compose screens)
Module splits
- •
api/orcontract/— Public interfaces (typical forapp/anddriving/) - •
impl/— Production implementations - •
test/— Fake/in-memory implementations for unit tests- •
driven/test/— Fakes for port interfaces (DB, API) - •
app/test/— Fakes for use case interfaces (cross-feature testing)
- •
Shared modules (feat/shared/)
- •
shared/database/— Shared database infrastructure - •
shared/rules/business/— Cross-cutting business rules (api/+impl/). Auto-wired to all feature modules.
Library modules (lib/)
Domain-agnostic reusable code used by driven and driving feature modules.
core modules can be used anywhere.
Dependency direction
driving -> app -> ports -> model -> business
driven -> app -> model -> business