# 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)

[Answer]: B