SluijsensandClaude Sonnet 5
274946dbff
Relocates ModuleOrchestrator, ServiceCollectionExtensions, and ApiPrefixConvention from SlpModularCms.Api into SlpModularCms.Core.Hosting so a new Master-less SlpModularCms.Api.Slave host project (ports 5285/7222) can share the same bootstrap code without duplicating it. This lets a developer run a master instance and a slave instance side by side locally to test the master/slave connection, without touching the existing master/slave protocol itself. Relocates the two orchestrator/convention test files from Modules.Identity.Tests to Core.Tests, dropping an incidental ProjectReference to SlpModularCms.Api that existed only for those tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
32 lines
2.6 KiB
Markdown
32 lines
2.6 KiB
Markdown
# Application Design — Local Dev Master/Slave Setup
|
|
|
|
Consolidated design summary. See individual files for full detail: `components.md`, `component-methods.md`, `services.md`, `component-dependency.md`.
|
|
|
|
## Key Decision
|
|
|
|
The only real design decision in this feature (no new business logic exists) is **how to share host bootstrap code between the master and slave processes without duplication (NFR-1)**. Resolved as: move `ModuleOrchestrator`, `ServiceCollectionExtensions`, and `ApiPrefixConvention` out of `SlpModularCms.Api` and into the existing `SlpModularCms.Core` project (new `SlpModularCms.Core.Hosting` namespace). Both host projects already reference `Core`, so this achieves a single shared copy with no new project and no file-linking, at the cost of two new package references on `Core` (`Asp.Versioning.Mvc`, `Microsoft.AspNetCore.OpenApi`) that it doesn't currently have.
|
|
|
|
## Components (see components.md)
|
|
1. `SlpModularCms.Core.Hosting` — relocated shared bootstrap code
|
|
2. `SlpModularCms.Api` — existing master host, now sources bootstrap from `Core.Hosting`
|
|
3. `SlpModularCms.Api.Slave` — new slave-only host, no `Modules.Master` reference
|
|
|
|
## Component Methods (see component-methods.md)
|
|
All method signatures are unchanged from today's implementation — only their namespace/location moves. Module exclusion for the slave is achieved entirely through the absence of a `ProjectReference`, not new conditional code.
|
|
|
|
## Services (see services.md)
|
|
No new domain services. Existing master-side (`CmsInstanceService`, `SlaveApiClient`) and slave-side (`MasterAvailabilityService`, `MasterApiKeyProtector`) services are reused unchanged. A sequence diagram documents the intended local verification flow (start both, use the existing Add CMS Instance dialog, confirm connected status).
|
|
|
|
## Component Dependencies (see component-dependency.md)
|
|
Dependency matrix and data-flow diagram showing both host projects depending on `Core` (+ `Modules.Availability`/`Modules.Identity`), with only `SlpModularCms.Api` additionally depending on `Modules.Master`. Each host uses its own local database; the frontend can target either host via `VITE_API_BASE_URL`.
|
|
|
|
## Traceability to Requirements
|
|
|
|
| Requirement | Design Element |
|
|
|---|---|
|
|
| FR-1 (slave-only host project) | `SlpModularCms.Api.Slave` component |
|
|
| NFR-1 (no duplication) | `Core.Hosting` relocation |
|
|
| FR-2 (distinct run config) | component-dependency.md ports/DB mapping |
|
|
| FR-3 (frontend against either instance) | component-dependency.md data-flow diagram |
|
|
| NFR-2 (DB isolation) | Separate `SlpModularCmsLocal_Master`/`SlpModularCmsLocal_Slave` in data-flow diagram |
|