Files

T

SluijsensandClaude Sonnet 5 274946dbff Adds SlpModularCms.Api.Slave for local master/slave dev testing (Unit 1)

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>

2026-07-04 02:07:35 +02:00

2.6 KiB

Raw Blame History

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)

SlpModularCms.Core.Hosting — relocated shared bootstrap code
SlpModularCms.Api — existing master host, now sources bootstrap from Core.Hosting
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

2.6 KiB Raw Blame History