03. Architecture Walkthrough
Why This Page Matters
After you understand the product story and the runtime vocabulary, the next question is:
- where does each kind of responsibility live?
This page is the newcomer bridge into the repo structure.
The Five Main Projects
The solution is split into:
InspectionPrototype.AppInspectionPrototype.PresentationInspectionPrototype.ApplicationInspectionPrototype.InfrastructureInspectionPrototype.Domain
Each project has a different role.
App
Owns startup composition:
- host startup
- dependency injection
- WPF application bootstrap
- app settings
Presentation
Owns UI projection:
- view models
- observable collections
- UI-facing display values
- command wiring from the UI into application services
Application
Owns behavior and coordination:
- canonical app state
- workflow orchestration
- command guards
- hosted background services
- abstractions for infrastructure seams
Infrastructure
Owns the outside-world details:
- simulator implementations
- file-backed recipe catalog
- file-backed run history store
- sample recipe provisioning
- simulator profile hydration
Domain
Owns stable contracts:
- recipes
- frames
- alarms
- summaries
The Dependency Story
The dependency direction matters:
Appcomposes everythingPresentationdepends onApplicationandDomainApplicationdepends onDomainInfrastructuredepends onApplicationandDomainDomainstays at the bottom
That is a clean, teachable structure because:
- the UI does not control the workflow directly
- infrastructure does not define the runtime rules
- domain remains the shared language layer
Quick Layer Map
App
|
+--> Presentation
| |
| +--> Application
| |
| +--> Domain
|
+--> Infrastructure
|
+--> Application
+--> DomainRead this diagram from top to bottom as “who composes whom” and from bottom to top as “which layer stays stable enough to be reused.”
The Most Important Cross-Cutting Design Choice
The most important architectural rule is:
- the application layer owns canonical state transitions
This comes from ADR-001 and is visible in:
AppStateAppStateStoreWorkflowServiceCommandGuardsMainViewModel
This one decision explains much of the rest of the code structure.
How To Walk The Code
A good newcomer walkthrough is:
- open
MainWindow.xaml - open
MainViewModel.cs - open
WorkflowService.cs - open
AppState.cs - open
ApplicationServiceCollectionExtensions.cs - open
InfrastructureServiceCollectionExtensions.cs
This path shows:
- what the UI exposes
- how the UI forwards commands
- where the runtime rules live
- where state lives
- how the app is composed
- which infrastructure pieces are plugged in
Why This Architecture Works For Teaching
This repo is particularly good for teaching because it does not hide its architecture behind too much framework magic.
You can see:
- where runtime truth lives
- where abstractions are introduced
- where file-backed boundaries are applied
- where simulation begins
- where tests attach
That makes the system easier to learn and easier to explain.
Related Pages
- Architecture Pack
- 02. Project and Layer Map
- 04. Workflow and Async Runtime
- 05. Design Patterns and .NET Techniques
Read Next
The best next page is:
Diagram Brief
Title: Newcomer architecture walkthroughPurpose: Show the five projects and the reading path a newcomer should take through themAudience: newcomer software engineerNodes: App, Presentation, Application, Infrastructure, Domain, MainWindow, MainViewModel, WorkflowService, AppState, JsonRecipeCatalog, JsonRunHistoryStoreEdges: App composes the rest; Presentation projects Application state; Application coordinates Infrastructure through abstractions; Domain contracts are shared beneath themGrouping: Project layers, representative files, recommended reading pathCaption: The repo becomes readable once you know which project owns startup, projection, orchestration, infrastructure, and contractsDestination file path:docs/diagrams/source/course-03-architecture-walkthrough.drawio