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>
25 lines
2.5 KiB
Markdown
25 lines
2.5 KiB
Markdown
# 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 `ProjectReference` to `Modules.Master` (and, by the same logic, to `Modules.Identity`/`Modules.Availability`) from `SlpModularCms.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)
|
|
|
|
[Answer]: A
|