Unit of Work Dependencies — Master CMS Module

Dependency Matrix

Unit	Depends On	Reason
Unit 1 — master-backend	`SlpModularCms.Core` only	No unit dependencies; builds the API contract that others consume
Unit 2 — slave-availability-extension	Unit 1 (API contract)	Slave endpoints must match what `ISlaveApiClient` calls; registration endpoint schema defined in Unit 1
Unit 3 — frontend-cms-page	Unit 1 (REST API)	Frontend hooks call `/api/v1/CmsInstances`; endpoint shapes must be finalized
Unit 4 — documentation	Units 1, 2, 3	Documents final patterns after all code is complete

Implementation Sequence

graph LR
    U1["Unit 1\nmaster-backend"]
    U2["Unit 2\nslave-availability-extension"]
    U3["Unit 3\nfrontend-cms-page"]
    U4["Unit 4\ndocumentation"]

    U1 --> U2
    U1 --> U3
    U2 --> U4
    U3 --> U4

    classDef unit1 fill:#9ae6b4,stroke:#2f855a,stroke-width:2px,color:#000
    classDef unit2 fill:#63b3ed,stroke:#2b6cb0,stroke-width:2px,color:#000
    classDef unit3 fill:#FFC107,stroke:#F57F17,stroke-width:2px,color:#000
    classDef unit4 fill:#CE93D8,stroke:#6A1B9A,stroke-width:2px,color:#000
    class U1 unit1
    class U2 unit2
    class U3 unit3
    class U4 unit4

Text alternative: Unit 1 (master-backend) must complete first; Unit 2 and Unit 3 both depend on Unit 1 and can be worked on in parallel after Unit 1 is done; Unit 4 (documentation) depends on all three.

Package Change Sequence

graph TD
    Core["SlpModularCms.Core\n(no changes)"]
    MasterMod["SlpModularCms.Modules.Master\nUnit 1 — new project"]
    AvailMod["SlpModularCms.Modules.Availability\nUnit 2 — extended"]
    Api["SlpModularCms.Api\nregisters Master module"]
    Frontend["frontend/\nUnit 3 — /cms page"]
    Docs["README.md\nfrontend/README.md\nUnit 4"]
    MasterTests["SlpModularCms.Modules.Master.Tests\nUnit 1 — new test project"]
    AvailMasterTests["SlpModularCms.Modules.Availability.Master.Tests\nUnit 2 — new test project"]

    Core --> MasterMod
    Core --> AvailMod
    MasterMod --> AvailMod
    MasterMod --> Api
    AvailMod --> Api
    Api --> Frontend
    Frontend --> Docs
    MasterMod --> MasterTests
    AvailMod --> AvailMasterTests

    classDef unchanged fill:#B0BEC5,stroke:#546E7A,stroke-width:1px,color:#000
    classDef unit1 fill:#9ae6b4,stroke:#2f855a,stroke-width:2px,color:#000
    classDef unit2 fill:#63b3ed,stroke:#2b6cb0,stroke-width:2px,color:#000
    classDef unit3 fill:#FFC107,stroke:#F57F17,stroke-width:2px,color:#000
    classDef unit4 fill:#CE93D8,stroke:#6A1B9A,stroke-width:2px,color:#000
    classDef tests fill:#FC8181,stroke:#C53030,stroke-width:1px,color:#000
    class Core,Api unchanged
    class MasterMod unit1
    class AvailMod unit2
    class Frontend unit3
    class Docs unit4
    class MasterTests,AvailMasterTests tests

Text alternative: Core unchanged; Unit 1 (Modules.Master) created first; Unit 2 (Availability extended) and Unit 3 (frontend) build on top; Api shell registers new module; Unit 4 docs come last; two new test projects created.

Inter-Unit API Contracts

The following interfaces form the boundary between units. These must be finalized during Unit 1 before Unit 2 and Unit 3 can proceed.

Contract	Defined In	Consumed By
`POST /api/internal/master/register`	Unit 2 (slave exposes it)	Unit 1 (`SlaveApiClient` calls it)
`GET /api/internal/master/registration`	Unit 2 (slave exposes it)	Unit 1 (`SlaveApiClient` calls it for integrity check)
`PUT /api/v1/Availability/admin/status`	Unit 2 (existing, unchanged)	Unit 1 (`SlaveApiClient` reuses it for status push)
`GET /api/v1/CmsInstances`	Unit 1 (master exposes it)	Unit 3 (`useCmsInstances` hook)
`POST /api/v1/CmsInstances`	Unit 1 (master exposes it)	Unit 3 (`useAddCmsInstance` hook)
`PUT /api/v1/CmsInstances/{id}/status`	Unit 1 (master exposes it)	Unit 3 (`useUpdateCmsInstanceStatus` hook)

Parallel Development Opportunities

After Unit 1 is complete and its API contracts are finalized:

Unit 2 and Unit 3 can be developed in parallel — they share no direct dependency on each other; both only depend on Unit 1's REST API contract
Unit 4 must wait for all three units to be complete

Risk Notes

Risk	Unit	Mitigation
Slave endpoint schema changes after Unit 2 starts	2	Finalize `ISlaveApiClient` method signatures in Unit 1 before Unit 2 construction begins
Frontend type drift from actual API response shape	3	Generate TypeScript types from Unit 1 `CmsInstanceDto` definition; keep in sync during code generation
Per-module migration pattern new to codebase	1, 2	Apply pattern in Unit 1 first; Unit 2 follows the same pattern

4.8 KiB Raw Blame History