Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Application architecture
Purpose
Engineering view of the proposed modular monolith. The product facts are owned by System-Components; this note adds only the engineering decisions layered on top.
Source notes
System-Components, API-and-Request-Pipeline, Deployment-and-Operations, Data-Model.
Current state
Proposed. No code exists.
Shape
One web and API codebase, one background worker from the same codebase, one private PostgreSQL database. Module boundaries are internal; separate business microservices are not required. Four modules: Identity-and-Company-Access, Opportunities-and-Discovery, Engagement-and-Tracking, Notifications-and-Administration. Manual DG services are staff procedures, not a module (DG-Manual-Services).
Engineering choices on top (all Proposed, owner to accept): stack profile (ADR-0001-Stack-Profile), polling outbox worker (ADR-0002-Outbox-Worker-No-Redis), row-level policies as defence in depth (ADR-0003-RLS-Defence-in-Depth), identifiers and idempotency (ADR-0004-UUIDv7-and-Idempotency), CI (ADR-0005-CI-on-Every-Pull-Request).
Trust boundaries
- Browser to API over HTTPS with a session. The browser holds no database or provider credential.
- API to PostgreSQL through scoped data access.
- Worker to email provider. Provider credentials are server-side only.
- Identity and email providers are DG decisions (Q09); code against Integration-Ports.
Invariants
Every request passes the pipeline in Request-Pipeline. A state change and its notification event commit in one transaction (Outbox-and-Worker). Modules call each other through service functions, never each other’s tables.
Open decisions
Blocked by Q09 for provider choice, region and retention.
Change history
| Date | Change |
|---|---|
| 2026-10-20 | Created (bootstrap Phase 2) |