# 07 — Architecture and Integrations

> Proposal §5 (Solution Architecture, integrations, quality requirements) has **not been written for TNSU yet**. Its current content is leftover template text from another project. Ignore it entirely, including the §5.1 paragraph and figure. The architecture principles below come only from proposal §1.1, §3.3, §4.1 and the team's use cases ([12-use-cases.md](12-use-cases.md)).

## Architecture principles

From the proposal [confirmed in proposal, §1.1, §3.3 (8), §4.1]:

- **Modular architecture** with modules switched on per phase.
- **Central shared data and services.** All subsystems use central data, with permissions and data scope separated by education level, campus, sports school and role.
- Supports **integration with external systems**. (The proposal also mentions a legacy "E-Education" system, but **no legacy system exists**; confirmed 2026-10-30. This is a greenfield build.)
- Security, permission management, and extensibility for future capabilities.

From the use cases [use cases]:

- Platform services are separate modules that business modules call: **IAM, ORG, NOTI, ENG, SVC, CASE, DOC, PRIV, AUD, ANA, RPT, ADMIN**. NOTI, AUD and LMS are pure background services.
- **Domain events** connect modules, e.g. `StudentStatusChanged` → `StudentExitCase` cascade, `ath.CompetitionLeaveApproved` consumed by ATT, `SectionCancelled` [use cases].
- **Rules as versioned DMN decision tables** (`PolicySet`, `FeePolicy`, `RefundRule`, `MakeupPolicy`, consent policy), applied per cohort.
- **Separate health vault** (`hlt_vault`) with its own access rules.
- **Audit:** WORM storage for data fixes, signed snapshots (hash) of grade sets and regulatory submissions, and an audit record of every read of sensitive cases.
- Data-fix scripts run through a pipeline, not a console, with extra approval for the `asm`, `rec` and `fin` schemas (W-137). This suggests per-module schemas [inferred].
- **Idempotent, synchronous registration transactions** behind a virtual waiting room (W-49).

## Likely platform-core services [inferred]

| Core service | UC modules | Proposal |
|---|---|---|
| Identity, roles, ABAC, delegation, PAM, recertification | IAM, ADMIN | TNSU-11 |
| Org units (central / 17 campuses / 13 schools), academic calendar, term rollover | ORG | TNSU-11 |
| Person and learner registry, guardian relations, status lifecycle | REC, SSC | TNSU-01/02 |
| Consent and data-subject rights | PRIV | — |
| Request, approval and e-Form engine, appeals and complaints | SVC, CASE | TNSU-09 |
| Documents, e-signature, credential verification, records retention | DOC, GRD | TNSU-09 |
| Notifications and announcements | NOTI, ENG | cross-cutting |
| Billing, payments, receipts, refunds, scholarships, กยศ. | FIN, SCH | TNSU-05 |
| Analytics, regulatory reporting | ANA, RPT | TNSU-10 |
| Audit log | AUD | TNSU-11 |

## Integrations

| System | Purpose | Source |
|---|---|---|
| **Payment: Thai QR / PromptPay** with bank callback or statement reconciliation; credit card per the proposal | Application fees, tuition, refunds | Proposal §1, use cases W-41, W-51, W-143 |
| **e-Receipt** | Electronic receipts | W-41, W-43, W-51 |
| **DGA** | e-Signature for certain document types | Proposal §1.1, §3.3 |
| **Digital signatures with LTV and a revocation list** | Credentials that employers can verify | W-67, W-132 |
| **กยศ. DSL** | Student loans, operated through the DSL portal (portal-assist, not an API) | W-48, W-119, W-133 |
| **ThaID** | Identity for applicants, guardians, alumni, step-up actions | W-41, W-127, W-142, … |
| **myTCAS / ทปอ.** | Optional TCAS adapter (file/API) | W-73 |
| **สป.อว. / CHECO** | Curriculum registration, graduate surveys, degree revocation | W-08, W-65, W-132 |
| **GFMIS / accounting** | Fiscal-year export | W-116 |
| **ตม.30** (immigration) | Report foreigners staying in dorms | W-38 |
| **ทะเบียนราษฎร์** | Name-change check (if connectable) | W-131 |
| **LMS** | Score import, account provisioning | W-01, W-44 |
| **SSO, e-mail, Wi-Fi, digital student card** | Provisioned at enrolment | W-44 |
| **LINE (LIFF), e-mail, SMS, in-app push** | Notifications; parent channel as LIFF/PWA | W-36, W-127, W-13 |
| **Reporting Hub** | Regulatory submissions | W-35 |

## Integration intake (collect per system, before its module is built)

Integrations are built **together with the module that needs them**. Until then, keep this basic information per system in this file (add a subsection per system as it arrives):

| Item | Notes |
|---|---|
| Owner and contact | Agency / bank / vendor, technical contact |
| Module(s) and use cases that need it | e.g. FIN → W-51 |
| Interface type | REST / SOAP / file exchange / portal-assist (manual in the owner's portal) |
| Authentication | API key, OAuth client, mTLS certificate, IP allow-list |
| Environments | Sandbox / UAT availability and how to get access |
| Data exchanged | Fields, direction, PII involved (and PDPA basis) |
| Volume and timing | Peak volume, batch vs. real time, callback behaviour |
| Agreement and cost | MOU / contract, per-transaction fees |
| Status | Not started / requested / sandbox ready / tested / production |

## Tech stack

Decided in [ADR-0001](../adr/0001-tech-stack.md): **Vue + Nuxt.js (SSR)**, **Go + Stream Framework** (Fiber, GORM, JWT + Redis sessions, queues), **RustFS** (S3), **Redis**, **Harbor**, **ArgoCD**, **Rancher**, **Kubernetes**, **OpenSearch + Dashboards** for centralised logs, **Grafana** for monitoring. **Database: SQL Server** (decided 2026-10-30; the customer already runs it), so queues use **RabbitMQ**.

## Not decided **[unknown]**

- SQL Server version / edition, and whether it runs on the customer's existing server or in the cluster (see ADR-0001).
- Hosting (government cloud or the university's own servers) and data residency.
- Multi-tenancy model: one database with unit scoping, or per-unit partitions.
- Mobile approach: native, cross-platform, or PWA/LIFF.
- AI provider and model, if the AI features stay in scope. No use case covers AI yet.
- Event / messaging technology for the domain events above (the framework offers PostgreSQL or RabbitMQ queues).
- WORM storage for audit evidence (e.g. RustFS object lock).

When you propose any of these, write it up as a decision record in `docs/adr/NNN-title.md` and link it from here.