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>
2.8 KiB
Application Design — Clarification
Contradiction: Q1 (file-linking) vs Q2 (move into Core)
You answered Q1 with C (MSBuild file-linking: keep the .cs files physically in one project, link them into the other so there's no new project) and Q2 with B (put the code directly into the existing SlpModularCms.Core project instead of a new project).
These two answers solve the same problem in different, mutually exclusive ways:
- C (file-linking) implies the source files stay in
SlpModularCms.Api(or wherever) and get linked (not copied) intoSlpModularCms.Api.Slave— two projects compiling the same files, still no single shared assembly. - B (move into Core) means the files move into
SlpModularCms.Core, which is already referenced by every project (both host projects, all modules) — no linking needed at all, because it becomes a normal shared dependency like everything else in Core.
Given your stated goal — "1 buildable project for production, no overhead for testing" — B fully supersedes C: moving the three classes (ModuleOrchestrator, ServiceCollectionExtensions, ApiPrefixConvention) into SlpModularCms.Core gives you exactly one copy of the code, compiled once, already available to both SlpModularCms.Api and SlpModularCms.Api.Slave via the existing Core reference — no new project, no file-linking, no extra overhead. File-linking would only be needed if you wanted to avoid touching Core, which contradicts choosing B.
Checked SlpModularCms.Core.csproj: it already has a FrameworkReference to Microsoft.AspNetCore.App (covers MVC, rate limiting, etc.) and already references Microsoft.AspNetCore.Authentication.JwtBearer and Microsoft.AspNetCore.Identity.EntityFrameworkCore. Moving the code in would require adding exactly two more package references to Core: Asp.Versioning.Mvc (for AddApiVersioning) and Microsoft.AspNetCore.OpenApi (for AddOpenApi) — both already used today, just currently referenced at the Api project level instead of Core.
Clarification Question 1
Confirm the resolution:
A) Yes — go with B: move ModuleOrchestrator, ServiceCollectionExtensions, and ApiPrefixConvention into SlpModularCms.Core (namespaces become SlpModularCms.Core.Hosting.* or similar). No new project, no file-linking. Core gains two package references (Asp.Versioning.Mvc, Microsoft.AspNetCore.OpenApi) it doesn't currently have. Both SlpModularCms.Api and SlpModularCms.Api.Slave call the same code via their existing Core reference.
B) No — actually use file-linking (C) instead, and leave Core untouched; the three classes stay physically in SlpModularCms.Api and get linked into SlpModularCms.Api.Slave's .csproj via <Compile Include="..." Link="..." />.
X) Other (please describe after Answer: tag below)