3.2 KiB
NFR Design Plan — Unit 1: master-backend
Unit Context
Unit: master-backend
Input: nfr-requirements.md, tech-stack-decisions.md, functional-design artifacts
Patterns to design: Polly resilience pipeline, Data Protection wiring, background service isolation
NFR Design Questions
Answer each question by filling in your choice after the [Answer]: tag.
Q1 — Data Protection: Injection Pattern
CmsInstanceService needs to encrypt/decrypt ApiKey via IDataProtector. How should it be injected?
A) Direct IDataProtectionProvider injection — inject IDataProtectionProvider in CmsInstanceService; call .CreateProtector("SlpModularCms.Master.ApiKey") in the constructor. Simple; no extra type; easy to test by mocking IDataProtectionProvider.
B) Thin IApiKeyProtector wrapper — define a small IApiKeyProtector interface with Protect(string) and Unprotect(string) methods; inject the interface into CmsInstanceService. Purpose is explicit; makes mocking in tests trivially simple (no need to mock ASP.NET Core Data Protection internals).
C) Other
Q2 — Polly Pipeline: Registration Scope
The Polly resilience pipeline (exponential backoff + timeout) applies to all SlaveApiClient calls. How should it be registered?
A) Single pipeline on AddResilienceHandler — configure one pipeline on the IHttpClientBuilder for SlaveApiClient; applies automatically to all HTTP calls made by this client. Zero per-call setup; consistent behavior across all slave endpoints.
B) Inline ResiliencePipeline per method — build and execute a ResiliencePipeline explicitly inside each SlaveApiClient method. More control per call (e.g., different timeout for integrity check vs. status push); more boilerplate.
C) Other
Q3 — CmsInstanceService Constructor Complexity
CmsInstanceService will inject: ICmsInstanceRepository, ISlaveApiClient, IDataProtectionProvider (or IApiKeyProtector), IOptions<MasterModuleOptions>, IHttpContextAccessor, ILogger<CmsInstanceService> — 6 dependencies. Is this acceptable?
A) Accept 6 dependencies — follows existing project pattern (PersistentAvailabilityService has similar dependencies); no need to introduce aggregation objects.
B) Introduce MasterServiceDependencies context record — wrap the 6 dependencies in a single record type to simplify the constructor signature. Cleaner constructor; slightly more indirection.
C) Other
Execution Steps
After all questions above are answered, the following artifacts will be generated:
- Step 1 — Analyze all answers; flag any ambiguities
- Step 2 — Generate
nfr-design-patterns.md— Polly pipeline design, Data Protection pattern, logging pattern, test isolation pattern - Step 3 — Generate
logical-components.md— infrastructure wiring diagram, component interaction for NFR patterns - Step 4 — Validate all Mermaid diagrams
- Step 5 — Update
aidlc-state.md - Step 6 — Present completion message for user approval
Artifact path: aidlc-docs/features/master-cms-module/construction/plans/master-backend-nfr-design-plan.md