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>
42 lines
2.6 KiB
Markdown
42 lines
2.6 KiB
Markdown
# Services — Local Dev Master/Slave Setup
|
|
|
|
## No new domain services
|
|
|
|
This feature introduces no new business/domain service. All existing services are reused unchanged:
|
|
|
|
- **Master-side** (only present in `SlpModularCms.Api`, because only it references `Modules.Master`): `CmsInstanceService`, `SlaveApiClient`, `ApiKeyProtector` — manage registered CMS instances and communicate with them.
|
|
- **Slave-side** (present in both `SlpModularCms.Api` and `SlpModularCms.Api.Slave`, since both reference `Modules.Availability`): `MasterAvailabilityService`, `MasterApiKeyProtector` — accept and validate a master's per-instance API key.
|
|
- **Shared cross-cutting**: `IAuthService`, `IInvitationService`, `ISetupService` (from `Core.Identity` via `AddCoreInfrastructure`) — identical in both hosts.
|
|
|
|
## Orchestration Service
|
|
|
|
`ModuleOrchestrator` (relocated to `SlpModularCms.Core.Hosting`, see components.md) is the only "orchestration" element in this feature, and its role is unchanged: at startup, discover whichever module DLLs are present next to the host executable and wire them into DI + the request pipeline. Its behavior naturally differs between the two hosts only because of what's present in each host's build output — not because of any new conditional logic.
|
|
|
|
## Interaction Sequence — Local Master/Slave Connection Test
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
box rgba(246,224,94,0.4) Developer
|
|
participant Dev as Developer
|
|
end
|
|
box rgba(99,179,237,0.4) Master Instance (5284/7221)
|
|
participant MasterApi as SlpModularCms.Api
|
|
participant CmsInstanceSvc as CmsInstanceService
|
|
end
|
|
box rgba(154,230,180,0.4) Slave Instance (5285/7222)
|
|
participant SlaveApi as SlpModularCms.Api.Slave
|
|
participant MasterCtrl as MasterController
|
|
end
|
|
|
|
Dev->>MasterApi: dotnet run --launch-profile master
|
|
Dev->>SlaveApi: dotnet run --launch-profile slave
|
|
Dev->>MasterApi: Open frontend, use Add CMS Instance dialog with slave URL
|
|
MasterApi->>CmsInstanceSvc: Register CMS instance (slave URL + generated API key)
|
|
CmsInstanceSvc->>MasterCtrl: Push registration / poll status using API key
|
|
MasterCtrl-->>CmsInstanceSvc: Accepted, status healthy
|
|
CmsInstanceSvc-->>MasterApi: Instance connected
|
|
MasterApi-->>Dev: CMS Instance shows as Connected
|
|
```
|
|
|
|
Text alternative: The developer starts the master and slave backends on their respective ports, then uses the master frontend's existing Add CMS Instance dialog. The master's CmsInstanceService registers and communicates with the slave's MasterController using a per-instance API key, and the frontend reflects the resulting connected status.
|