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.5 KiB
Requirements Clarification — Follow-up
Your Question 1 answer combines two different concerns, and I want to scope this feature correctly before writing requirements.
Ambiguity 1: Scope of the module-loading change
You answered Q1 with: "For testing purposes a separate project will suffice, but when building the production builds later I want to be able to build the base version of the API and add the modules as DLL-files. Can we make that happen here as well?"
Today, SlpModularCms.Modules.Master is a ProjectReference in SlpModularCms.Api.csproj, so it's always compiled straight into the API's own build output — ModuleOrchestrator then discovers it there via DLL-scanning. A true "base API + drop in module DLLs later" production model would mean:
- Removing the
ProjectReferencetoModules.Master(and, by the same logic, toModules.Identity/Modules.Availability) fromSlpModularCms.Api.csproj. - Introducing a separate "Modules" output/probing folder that the API loads DLLs from at startup (instead of its own bin folder), populated by copying built module DLLs into it (a packaging/deployment concern).
- Deciding what happens to module-specific EF Core migrations, DI wiring, and versioning across independently-built modules.
This is a meaningfully bigger architectural change than "add a config flag to skip the Master module for a local slave test instance" — it touches build/packaging (.csproj structure, CI/CD artifacts) well beyond local dev tooling.
Clarification Question 1
How do you want to handle this?
A) Keep this feature scoped to local dev only: a separate SlpModularCms.Api.Slave test host project (no Modules.Master reference) for running master+slave locally. Capture the "base API + drop-in module DLLs for production" idea as a new tech-debt-backlog / future-feature item to design properly on its own later.
B) Expand this feature to also implement the production drop-in-DLL loading model now (restructure SlpModularCms.Api.csproj to not directly reference module projects, add a module-probing folder loaded at runtime, update ModuleOrchestrator accordingly) — understanding this is a larger, riskier change touching the deployment model, not just local dev.
C) Do the config-driven Modules:Disabled toggle from the original option A instead (one shared build, no separate project, no production refactor) — simplest for local dev, defers the production plugin model entirely.
X) Other (please describe after Answer: tag below)