Architecture overview

Purpose

Give contributors a single mental model before touching files: what runs where, and which direction dependencies flow.

Code location

• Solution: multiple projects under repo root; primary boundaries are project names Mnemo.Core, Mnemo.Infrastructure, Mnemo.UI.

The three layers

Layer	Responsibility	Depends on
Mnemo.Core	Domain models, service interfaces, cross-cutting contracts without implementations	Baseline BCL / nothing UI
Mnemo.Infrastructure	SQLite storage, AI orchestration, note/flashcard services, import/export, platform glue	Core interfaces
Mnemo.UI	Avalonia views/view models, module classes, shell (MainWindow), user-visible workflows	Core + Infrastructure

Rule of thumb: Core never references Infrastructure or UI. UI references Infrastructure for composition root wiring inside Bootstrapper.

Main interfaces / classes

• Bootstrapper (Mnemo.UI/Services/Bootstrapper.cs) — composition root: registers Infrastructure + UI services, discovers IModule, builds IServiceProvider.
• IModule (Mnemo.Core/Services/IModule.cs) — feature plugin contract for routes, sidebar, DI, tools, widgets, translations, keybind manifests.

Startup / registration flow

See Startup flow for ordered steps (DI → module discovery → route registration).

How to extend

• New business capability that must stay testable: define interface in Core, implement in Infrastructure, consume from UI/modules.
• New screen: implement or extend an IModule in UI (see Module system).

Gotchas

• Putting implementations in Core breaks layering and bloating Core models with UI types pollutes everyone.
• Starting async work inside App.OnFrameworkInitializationCompleted incorrectly can break Avalonia desktop lifetime—follow patterns in App.axaml.cs.

---

Next: Core, Infrastructure, UI