Files
slp-modular-cms/aidlc-docs/features/local-dev-master-slave-setup/inception/application-design/components.md
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

4.5 KiB

Components — Local Dev Master/Slave Setup

1. SlpModularCms.Core.Hosting (new namespace within existing SlpModularCms.Core project)

Purpose: Single, shared home for the ASP.NET Core host bootstrap/orchestration code that both the master and slave API hosts use identically.

Responsibilities:

  • Discover and instantiate IModule implementations from the host's own build output directory (unchanged behavior).
  • Register core cross-cutting services (DB context, Identity, JWT auth, authorization policies, exception handling, API versioning, OpenAPI, CORS, rate limiting) shared by every instance regardless of which optional modules (e.g. Modules.Master) are present.
  • Apply the api/v1 route prefix convention to all discovered controllers.

Interfaces: Unchanged public API — ModuleOrchestrator (class), AddCoreInfrastructure/AddCmsCors/AddCmsRateLimiting (extension methods on IServiceCollection), ApiPrefixConvention (implements IApplicationModelConvention). Only the namespace moves (SlpModularCms.Api.Extensions/SlpModularCms.Api.InfrastructureSlpModularCms.Core.Hosting).

Not responsible for: Any module-specific business logic — modules remain fully self-contained (Modules.Master, Modules.Availability, Modules.Identity).

2. SlpModularCms.Api (existing project, master host)

Purpose: The main CMS instance — full stack, including the Master module, used for day-to-day development and as the "master" side of a local master/slave test.

Responsibilities: Unchanged from today. Program.cs now sources ModuleOrchestrator/ServiceCollectionExtensions/ApiPrefixConvention from SlpModularCms.Core.Hosting instead of its own local files.

Interfaces: No change — same controllers, same routes, same behavior. Its own copies of ModuleOrchestrator.cs, Extensions/ServiceCollectionExtensions.cs, Infrastructure/ApiPrefixConvention.cs are deleted (moved to Core).

Project references: Core (now including the hosting code), Modules.Availability, Modules.Identity, Modules.Master — unchanged set, just implicitly picks up Core.Hosting via the existing Core reference.

3. SlpModularCms.Api.Slave (new project)

Purpose: A minimal, Master-less host used purely as a local target for testing the master↔slave connection. Not intended for end-user CMS administration beyond what's needed to validate connectivity.

Responsibilities: Bootstraps identically to SlpModularCms.Api (via Core.Hosting), but its build output never contains SlpModularCms.Modules.Master.dll, so ModuleOrchestrator.DiscoverModules never loads the Master module for this instance.

Interfaces: Same shape as SlpModularCms.Api (Program.cs calling into Core.Hosting), minus anything Master-specific (there is none in Program.cs today — the exclusion works purely through the project-reference/build-output mechanism).

Project references: Core, Modules.Availability, Modules.Identity. Deliberately no reference to Modules.Master.

Configuration: Own appsettings.json / appsettings.Development.json / appsettings.local.json (gitignored) and own launchSettings.json (ports 5285 HTTP / 7222 HTTPS), per FR-2 in requirements.md.

Component Diagram

graph TD
    Core["SlpModularCms.Core<br/>(incl. new Core.Hosting)"]
    Master["SlpModularCms.Modules.Master"]
    Avail["SlpModularCms.Modules.Availability"]
    Ident["SlpModularCms.Modules.Identity"]
    ApiMaster["SlpModularCms.Api<br/>(master host)"]
    ApiSlave["SlpModularCms.Api.Slave<br/>(slave host, new)"]

    ApiMaster --> Core
    ApiMaster --> Master
    ApiMaster --> Avail
    ApiMaster --> Ident
    ApiSlave --> Core
    ApiSlave --> Avail
    ApiSlave --> Ident
    Master --> Core
    Avail --> Core
    Ident --> Core

    classDef core fill:#63b3ed,stroke:#2b6cb0,stroke-width:1px,color:#000;
    classDef module fill:#9ae6b4,stroke:#2f855a,stroke-width:1px,color:#000;
    classDef host fill:#f6e05e,stroke:#c05621,stroke-width:1px,color:#000;
    class Core core;
    class Master,Avail,Ident module;
    class ApiMaster,ApiSlave host;

Text alternative: Two host projects (SlpModularCms.Api and the new SlpModularCms.Api.Slave) both depend on Core (which now includes the shared hosting/bootstrap code) and on Modules.Availability/Modules.Identity. Only SlpModularCms.Api additionally depends on Modules.MasterSlpModularCms.Api.Slave deliberately omits that reference. All three module projects depend on Core.