In this chapter
7.1 Recommendation and rationale
The proposed first target is a modular application with an authoritative relational store and recoverable background work. This is a scenario-specific response to limited operating capacity and a need for transactional integrity. It is not a statement that a modular application is suitable for every institutional platform. The target keeps workflow transitions, permission decisions and request versions close to their authoritative data. Reporting and notification delivery are separated logically because they can tolerate delay and have different failure behaviour. That separation can be implemented within a controlled deployment before introducing independently operated services.
7.2 Logical architecture
The browser sends an authenticated command with an expected version and stable command identity. The API derives the actor from authenticated context, checks organizational scope and validates the transition. A transaction records the new state, audit entry, command result and any outbox intention. The worker processes committed background work. A notification failure must not undo an accepted approval. The report projection identifies its source and processing cut-off. Attachment storage, identity provider and backup destination remain separate controlled boundaries even when omitted from a simplified drawing.
7.3 Successful journey and rejected journey
| Step | Successful path | Explicit failure response |
|---|---|---|
| Submit | One accepted request version is recorded | Invalid or incomplete data receives a defined rejection |
| Review | Authorized actor inspects the current version | Wrong department or withdrawn authority is refused |
| Approve | Permitted transition commits atomically | Stale version causes a conflict requiring review |
| Fulfil | Execution references the approved version | Changed or cancelled authority prevents execution |
| Report | Defined source state enters a reconciled projection | Missing coverage is exposed or publication withheld |
Do not conflate a rejected command with a failed service. A forbidden approval may be correct system behaviour. Telemetry and support procedures must distinguish business rejection, technical failure and an outcome the client cannot yet determine.
7.4 Concurrency and recovery boundary
A read followed by an unconditional update is not sufficient to protect an approval version. Select a conditional update or locking strategy and test competing sessions. Scope command keys, compare repeated payloads and decide their retention. Transaction isolation is a mechanism to choose deliberately, not a label guaranteeing every invariant. The architectural acceptance includes a lost response after commit, a concurrent edit before approval and a stopped worker. Each scenario must leave the authoritative state explainable. The exact implementation belongs to the design package and code review; this dossier does not claim that the example has been built.
7.5 Target review outputs
Produce a context diagram, logical view, state-transition definition, trust boundaries and failure scenarios. Link each target element to a requirement or gap. If a component has no responsibility, requirement or operational owner, remove it or explain why it is needed.