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

3.2 KiB

Raw Permalink Blame History

Application Design Plan — Local Dev Master/Slave Setup

Scope

This feature has no new business logic or data model — the only real "component design" decision is how to share bootstrap/orchestration code (ModuleOrchestrator, ServiceCollectionExtensions, ApiPrefixConvention) between SlpModularCms.Api (master) and the new SlpModularCms.Api.Slave project, per NFR-1 (no duplication) from requirements.md.

Investigated: all three classes are public, live in SlpModularCms.Api.Extensions/SlpModularCms.Api.Infrastructure, and only depend on SlpModularCms.Core.* namespaces (Core.Data, Core.Identity.*, Core.Availability, Core.Modules) — none of them reference Modules.Master, Modules.Identity, or Modules.Availability directly. This means they can move to a shared project without dragging in the Master module.

Design Plan

Decide shared bootstrap extraction approach (Question 1)
Decide shared project name/location (Question 2)
Generate components.md — the two host projects + the new shared bootstrap component
Generate component-methods.md — public extension methods / orchestrator methods, signatures unchanged from today
Generate services.md — confirm no new domain services (reuses existing Modules.Master/Modules.Availability/Modules.Identity services untouched)
Generate component-dependency.md — dependency matrix for SlpModularCms.Api, SlpModularCms.Api.Slave, and the shared bootstrap project
Generate consolidated application-design.md

Questions

Question 1

How should the shared bootstrap code (ModuleOrchestrator, ServiceCollectionExtensions, ApiPrefixConvention) be shared between the master and slave host projects?

A) Move all three classes into a new shared class library project that both SlpModularCms.Api and SlpModularCms.Api.Slave reference (clean separation, standard .NET pattern, one source of truth). B) Keep the classes in SlpModularCms.Api and have SlpModularCms.Api.Slave reference SlpModularCms.Api itself — rejected in requirements analysis because SlpModularCms.Api.csproj references Modules.Master, which would defeat the purpose of a Master-less slave; listed here only for completeness. C) Use MSBuild file-linking (<Compile Include="..\SlpModularCms.Api\...\*.cs" Link="..." />) to share the same .cs files across both projects without a new class library. X) Other (please describe after Answer: tag below)

Answer: C, because I want 1 buildable project for production. I dont want to create extra overhead for testing purposes

Question 2

What should the new shared project be named, and what should it depend on?

A) SlpModularCms.Api.Hosting — new class library referencing only SlpModularCms.Core; contains ModuleOrchestrator, ServiceCollectionExtensions, ApiPrefixConvention (namespaces updated to SlpModularCms.Api.Hosting.*). Both SlpModularCms.Api and SlpModularCms.Api.Slave reference it plus their own module project references (Master only for the master host). B) Add this code directly into the existing SlpModularCms.Core project instead of creating a new project. X) Other (please describe after Answer: tag below)

3.2 KiB Raw Permalink Blame History