# Application Design — SlpSoftware Production API

Consolidated summary. See the companion documents for full detail:
- [components.md](components.md) — component identification and responsibilities
- [component-methods.md](component-methods.md) — method signatures per component
- [services.md](services.md) — service-layer orchestration patterns
- [component-dependency.md](component-dependency.md) — dependency matrix and data-flow diagrams

## Design Decisions (traced to application-design-plan.md)

| # | Decision | Source |
|---|---|---|
| AD-1 | `CmsHost` exposes two granular methods (`ConfigureServices`, `ConfigurePipeline`) rather than one all-owning entrypoint — each Client project keeps a visible, thin `Program.cs`. | Q1 = B |
| AD-2 | The `Offerings` module follows the Repository+Service pattern, consistent with `Modules.Master`, even though the module itself is simple CRUD. | Q2 = A |
| AD-3 | `OfferingsController` is a single controller with per-action authorization (`[AllowAnonymous]` on the public `GET`, `AdminOnly` on everything else), not split into two controllers. | Q3 = B |
| AD-4 | New offerings get a system-generated `Guid` `Id`, not an admin-provided slug. | Q4 = A |
| AD-5 | Deleting an offering is a soft delete (`IsDeleted`/`DeletedAt`), filtered out of all reads — a partial, lightweight answer to the SECURITY-13 open item from requirements.md, without introducing a full audit-log mechanism. | Q5 = B |

## Component Overview

8 components: the shared `CmsHost` composition helper, the new `SlpModularCms.Api.SlpSoftware` Client project, and 6 components making up `SlpModularCms.Modules.Offerings` (`Offering` entity, `OfferingsDbContext`, `IOfferingRepository`/`OfferingRepository`, `IOfferingsService`/`OfferingsService`, `OfferingsController`, `OfferingsModule`).

## Consistency Check Against Requirements and Stories

| Requirement / Story | Covered By |
|---|---|
| FR-1 (new Client project) | `SlpModularCms.Api.SlpSoftware` component |
| FR-2 (module composition) | Component-dependency.md — project-reference-driven module discovery |
| FR-3 (shared hosting extraction) | `CmsHost` component + methods |
| FR-4 (new module) | `OfferingsModule` + all Offerings sub-components |
| FR-5 (`Offering` entity) | `Offering` entity component |
| FR-6 (public endpoint) | `OfferingsController.GetOfferings`, `IOfferingsService.GetPublicOfferingsAsync` |
| FR-7 (admin CRUD) | `OfferingsController` admin actions, `IOfferingsService` Create/Update/Delete/Reorder/MoveUp/MoveDown |
| FR-8 (reference content) | No new component — content stays documented in requirements.md; entered manually by the user through the admin CRUD once built |
| FR-9 (CI/CD retarget) | Out of scope for Application Design — Operations phase |
| US-01/US-02/US-03 | `GetPublicOfferingsAsync` + `OfferingDto` shape (featured flag, empty-array-safe) |
| US-04/US-05 | `CreateAsync`/`UpdateAsync` |
| US-06/US-07 | `DeleteAsync` (soft delete, always allowed) |
| US-08 | `ReorderAsync` |
| US-09 | `MoveUpAsync`/`MoveDownAsync` |
| US-10 | Featured-exclusivity orchestration in `IOfferingsService` (services.md pattern 1) |
| US-11 | Validation is a `OfferingsController`/request-model concern (SECURITY-05) — detailed in Functional Design |
| US-12 | `AdminOnly` policy on all mutating actions (AD-3) |

No gaps found: every functional requirement and user story maps to at least one component or method defined above. Detailed business-rule logic (exact exclusivity transaction handling, reorder boundary behavior, field-level validation rules) is intentionally deferred to Functional Design for the Offerings unit, per Application Design's scope.