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).
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→StudentExitCasecascade,ath.CompetitionLeaveApprovedconsumed 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,recandfinschemas (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: 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.