Software Design Document

Template & Panduan Penulisan

Untuk Technical Lead, Software Architect, Backend Developer, Frontend Developer, DevOps Engineer, Business Analyst, Quality Assurance, dan Security Reviewer

Versi 2.0 | 2026

---

Panduan Penggunaan Template

Template ini dirancang untuk membantu tim teknis dalam mendokumentasikan desain arsitektur dan detail teknis sistem sebelum dan selama proses pengembangan. Disusun berdasarkan IEEE 1016, ISO/IEC/IEEE 42010, NIST SSDF, OWASP ASVS, dan praktik industri terbaik.

Tujuan Dokumen Ini

• Menerjemahkan kebutuhan fungsional (dari PRD) menjadi desain teknis yang dapat diimplementasi
• Mendokumentasikan keputusan arsitektur dan alasan di baliknya (Architecture Decision Records)
• Menjadi acuan tunggal untuk desain komponen, data model, dan kontrak antar-layer
• Memfasilitasi onboarding developer baru dengan pemahaman sistem yang komprehensif
• Menjadi dasar untuk code review, testing strategy, dan validasi implementasi
• Mendukung audit, handover, dan pemeliharaan sistem jangka panjang

Perbedaan SDD dengan Dokumen Lain

Aspek	BRD	PRD	SDD
Fokus	Kebutuhan bisnis	Kebutuhan produk & fitur	Desain teknis & arsitektur
Audiens	Stakeholder bisnis	PM, BA, QA, Dev	Developer, Tech Lead, DevOps
Pertanyaan	"Apa yang dibutuhkan bisnis?"	"Apa yang harus dibangun?"	"Bagaimana sistem dibangun?"
Waktu	Sebelum PRD	Setelah BRD	Setelah PRD
Detail	Proses bisnis, ROI	Fitur, AC, flow	Arsitektur, komponen, data model

Kapan Menggunakan SDD

• Proyek baru yang memerlukan arsitektur dari nol
• Fitur besar yang mengubah arsitektur existing (cross-module, cross-service)
• Integrasi dengan sistem eksternal yang kompleks
• Migrasi atau refactoring arsitektur

Untuk fitur kecil yang tidak mengubah arsitektur, cukup gunakan development plan per-backlog.

Cara Menggunakan Template

1. Baca seluruh template untuk memahami struktur SDD
2. Isi setiap bagian sesuai kebutuhan proyek -- hapus bagian yang tidak relevan dengan mencatat alasan di tabel tailoring (Bagian 1.6)
3. Gunakan tanda [ISI DI SINI] sebagai penanda bagian yang perlu diisi
4. Sertakan diagram (dapat berupa link ke diagram tool atau deskripsi tekstual)
5. Perbarui SDD jika ada perubahan arsitektur signifikan selama development
6. Dapatkan review dan persetujuan dari reviewer yang ditentukan sebelum implementasi dimulai

Alur Penulisan yang Direkomendasikan

Tahap	Output Utama	Review
1. Establish control	Metadata, pemilik, repositori, riwayat revisi, tailoring	Document owner
2. Definisikan batasan	Tujuan, ruang lingkup, aktor, asumsi	PM + Architect
3. Identifikasi driver	Kapabilitas, skenario NFR, constraint, regulasi, risiko	Architecture workshop
4. Buat context & views	Context, container, data, deployment, security views	Architecture review
5. Dekomposisi komponen	Tanggung jawab, interface, data ownership, dependensi	Engineering review
6. Spesifikasi kontrak & data	API/event/file contracts, ERD, data dictionary, migrasi	Integration + data review
7. Tambahkan behavioral design	Sequence, state, rules, algoritma, failure path	Engineering + QA
8. Tambahkan security & NFR	Threat model, kontrol, budget, resiliensi, DR	Security + NFR review
9. Tambahkan deployment & operations	Environment, topologi, pipeline, observability, runbook	Operational readiness
10. Trace & approve	RTM, temuan, evidence, approval, baseline	Formal gates

Panduan Peran Tim

Peran	Fokus Area	Kontribusi Utama	Review/Approval
Technical Lead / Architect	Keseluruhan desain, keputusan arsitektur	Mendefinisikan arsitektur, review komponen, approve perubahan	Architecture approval
Backend Developer	API design, service layer, data access	Mendetailkan desain backend, query, business logic flow	Implementation readiness
Frontend Developer	Component architecture, state management	Mendetailkan desain frontend, component tree, data flow	Implementation readiness
DevOps / SRE	Infrastructure, deployment, networking	Mendetailkan desain deployment, scaling, monitoring, runbook	Operational readiness
Security Reviewer	Threat model, authn/authz, data protection	Validasi kontrol keamanan, trust boundary, audit	Security approval
Business Analyst	Validasi terhadap requirement	Memastikan desain mencakup semua kebutuhan dari PRD	Business acceptance
Quality Assurance	Testability, observability, traceability	Memastikan desain dapat diuji, RTM lengkap	Test readiness
Project Manager	Scope, timeline, risiko	Validasi kelengkapan scope, risiko, dan dependensi	Business acceptance

Notasi dan Format

• TIPS: Panduan atau penjelasan tambahan untuk membantu pengisian.
• [ISI DI SINI] menunjukkan bagian yang harus diisi sesuai konteks proyek.
• Tag peran menunjukkan bagian yang paling relevan:
  • DEV Developer (Backend/Frontend/DevOps)
  • BA Business Analyst
  • QA Quality Assurance
  • PM Project Manager
  • SEC Security Reviewer

Kualitas SDD yang Baik

Kualitas	SDD yang Baik	SDD yang Lemah
Spesifik	Menyebut nama komponen, protokol, data, aturan, perilaku gagal, threshold, dan pemilik	Pernyataan samar seperti "aman dan scalable"
Konsisten	Diagram, tabel, struktur kode, kontrak, dan deployment menggunakan nama dan batasan yang sama	Nama komponen berbeda di diagram yang berbeda
Testable	NFR dan kontrol memiliki kriteria pass yang terukur dan metode verifikasi	Target subjektif atau tidak ada
Traceable	Requirements dan risiko terhubung ke keputusan, komponen, kontrol, tes, dan evidence	Keputusan desain tidak bisa ditelusuri ke driver
Operable	Monitoring, alert, recovery, backup, runbook, dan ownership yang actionable	Desain berhenti di struktur kode saja
Maintainable	SDD mereferensi artefak yang terkontrol dan memiliki proses update	Dokumen langsung usang begitu ditulis

Dokumen Masukan yang Direkomendasikan

DEV PM Technical Lead dan Project Manager bertanggung jawab mengumpulkan dokumen masukan berikut sebelum penyusunan SDD dimulai.

No	Dokumen Masukan	Deskripsi	Wajib / Opsional
1	PRD yang telah disetujui	Product Requirements Document sebagai dasar utama desain teknis	Wajib
2	BRD yang telah disetujui	Business Requirements Document untuk konteks bisnis dan aturan bisnis	Wajib
3	Dokumentasi infrastruktur / topologi jaringan	Arsitektur infrastruktur existing (server, network, firewall, load balancer)	Wajib
4	Akses ke repository kode (jika sistem existing)	Source code dan struktur proyek untuk memahami arsitektur yang sudah ada	Wajib (jika ada sistem existing)
5	Database schema existing	ERD, tabel, kolom, dan relasi dari database yang sudah berjalan	Wajib (jika ada DB existing)
6	Dokumentasi API sistem eksternal	Spesifikasi API dari sistem yang akan diintegrasikan (Swagger, Postman, WSDL)	Wajib (jika ada integrasi)
7	Standar keamanan / compliance checklist	Kebijakan keamanan organisasi, standar enkripsi, regulasi (ISO 27001, OWASP, dll.)	Wajib
8	Wireframe / desain UI final	Rancangan antarmuka dari tim UI/UX sebagai acuan desain frontend	Wajib (jika ada frontend)
9	Standar validasi form (TSG)	Aturan umum validasi form isian TSG	Wajib
10	Standar audit trail (TSG)	Panduan pencatatan audit trail, activity log, dan history TSG	Wajib
11	Daftar fitur utilitas sistem (TSG)	Standar fitur monitoring, notifikasi, health check TSG	Wajib
12	Kategori temuan major SIT (TSG)	14 kategori temuan major untuk kesiapan System Integration Testing	Wajib
13	Hasil load test / benchmark (jika ada)	Data performa sistem existing untuk baseline NFR	Opsional
14	Runbook / SOP operasional existing	Prosedur deployment, backup, recovery, monitoring yang sudah berjalan	Opsional
15	Architecture Decision Records (ADR) sebelumnya	Keputusan arsitektur yang sudah dibuat di fase sebelumnya	Opsional

TIPS: SDD tidak boleh dimulai sebelum PRD disetujui (no. 1). Untuk proyek greenfield, dokumen no. 4-5 tidak diperlukan. Untuk proyek dengan integrasi kompleks, pastikan no. 6 tersedia sebelum memulai desain API.

---

1. Document Control

1.1 Informasi Dokumen

Atribut	Detail
Nama Dokumen	Software Design Document (SDD)
Kode Dokumen	TSG-SDD-[KODE PROYEK]-[NOMOR URUT]
Proyek / Produk	[ISI DI SINI]
System Release	[ISI DI SINI]
Versi Dokumen	[ISI DI SINI — contoh: 1.0]
Status	Draft / In Review / Approved / Superseded
Klasifikasi	Internal / Confidential / Restricted
Tanggal Dibuat	[ISI DI SINI]
Tanggal Diperbarui	[ISI DI SINI]
Pemilik Dokumen	[ISI DI SINI -- Technical Lead / Architect]
Lokasi Repositori	[ISI DI SINI -- URL atau path terkontrol]
Siklus Review	[ISI DI SINI -- Per release / Per quarter / Lainnya]

1.2 Riwayat Versi

Versi	Tanggal	Penulis	Deskripsi Perubahan	Status
0.1	[ISI DI SINI]	[ISI DI SINI]	Draft awal arsitektur	Draft
0.2	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	In Review
1.0	[ISI DI SINI]	[ISI DI SINI]	Approved baseline untuk [RELEASE]	Approved

1.3 Review dan Persetujuan

Peran	Nama	Scope Review	Keputusan	Tanggal
Technical Lead / Architect	[ISI DI SINI]	Kelengkapan dan konsistensi arsitektur	Approve / Rework	[ISI DI SINI]
Engineering Lead	[ISI DI SINI]	Kesiapan implementasi	Approve / Rework	[ISI DI SINI]
Security Reviewer	[ISI DI SINI]	Desain keamanan dan privasi	Approve / Rework	[ISI DI SINI]
QA / Test Lead	[ISI DI SINI]	Verifiabilitas dan traceability	Approve / Rework	[ISI DI SINI]
DevOps / SRE	[ISI DI SINI]	Deployment dan operational readiness	Approve / Rework	[ISI DI SINI]
Project Manager	[ISI DI SINI]	Business alignment dan limitasi	Approve / Rework	[ISI DI SINI]

1.4 Identifikasi Sistem

Atribut	Value
Nama Sistem / Aplikasi	[ISI DI SINI]
Akronim	[ISI DI SINI]
Business Owner	[ISI DI SINI]
Technical Owner	[ISI DI SINI]
Service Criticality	[ISI DI SINI -- Tier / Classification]
Data Classification	[ISI DI SINI -- Internal / Confidential / Restricted]
Primary Repository	[ISI DI SINI -- URL / Path]

1.5 Dokumen Referensi

Kode Dokumen	Judul Dokumen	Versi	Lokasi / Pemilik	Relevansi
TSG-BRD-[KODE]	Business Requirements Document	[ISI DI SINI]	[ISI DI SINI]	Kebutuhan bisnis yang menjadi dasar desain
TSG-PRD-[KODE]	Product Requirements Document	[ISI DI SINI]	[ISI DI SINI]	Kebutuhan fungsional yang diterjemahkan ke desain
TSG-STD-VALIDASI	Aturan Umum Validasi Form	[ISI DI SINI]	[ISI DI SINI]	Standar validasi input
TSG-STD-AUDIT	Standar Audit Trail	[ISI DI SINI]	[ISI DI SINI]	Standar logging dan audit
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

1.6 Tailoring (Penyesuaian Template)

TIPS: Catat setiap bagian yang dihilangkan, digabung, atau diganti. Bagian yang dihilangkan hanya diperbolehkan dengan alasan dan persetujuan yang jelas.

Bagian	Keputusan	Alasan	Approver
[ISI DI SINI]	Included / Omitted / Combined / External Ref	[ISI DI SINI]	[ISI DI SINI]

---

2. Executive Summary

PM BA -- Bagian ini ditulis TERAKHIR setelah seluruh desain selesai. Rangkum arsitektur yang disetujui, keputusan utama, risiko kritis, dan batasan release dalam 1-2 halaman.

2.1 Ringkasan Desain Sistem

Item	Ringkasan
Tujuan sistem	[ISI DI SINI -- satu paragraf]
Pengguna utama & channel	[ISI DI SINI -- grup user, web, mobile, API, batch, dll.]
Gaya arsitektur	[ISI DI SINI -- Modular Monolith / Microservices / Event-Driven / Layered / Lainnya]
Technology stack utama	[ISI DI SINI -- Frontend, Backend, Data, Integration, Platform]
Model deployment	[ISI DI SINI -- Cloud / On-premises / Hybrid; Region / Data Center]
Model keamanan	[ISI DI SINI -- Identity Provider, Authorization Model, Trust Boundaries]
Target availability	[ISI DI SINI -- SLO / SLA]
Dependensi utama	[ISI DI SINI -- sistem / provider eksternal]
Batasan release	[ISI DI SINI -- apa yang di-approve oleh SDD ini]

CONTOH:

Item	Ringkasan
Tujuan sistem	Platform pengelolaan keuangan internal end-to-end: pengajuan pembayaran, approval, pencairan, pelaporan
Pengguna utama & channel	5.000 karyawan via web browser (intranet + VPN), 40+ cabang
Gaya arsitektur	Modular Monolith dengan Clean Architecture (Handler → Service → Repository)
Technology stack utama	Go (Fiber), React (TypeScript), SQL Server, Redis, MinIO
Model deployment	On-premises, Kubernetes, 3 environment (Dev/Staging/Production)
Model keamanan	OAuth 2.0 + JWT via UIM Next-G, Casbin RBAC, MFA untuk approver
Target availability	99.5% uptime, RTO 4 jam, RPO 1 jam
Dependensi utama	UIM Next-G (SSO), HCS (data karyawan), DWH (reporting), Core Banking (fase 2)
Batasan release	Release 1.0: Modul Auth, Payment, Dashboard, Admin. Excludes: Mobile, Escrow, Core Banking integration

2.2 Keputusan Arsitektur Utama

ADR ID	Keputusan	Alasan	Trade-off Utama
ADR-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
ADR-002	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

ADR ID	Keputusan	Alasan	Trade-off Utama
ADR-001	Modular Monolith, bukan Microservices	Tim kecil (8 dev), deployment sederhana, shared DB mengurangi kompleksitas integrasi	Scaling terbatas per-modul; harus refactor jika perlu independent scaling
ADR-002	SQL Server, bukan PostgreSQL	Klien sudah memiliki lisensi dan DBA expertise untuk SQL Server	Vendor lock-in, fitur JSON/full-text search lebih terbatas
ADR-003	Casbin RBAC, bukan custom permission	Mature library, policy-as-config, mendukung multi-tenant di masa depan	Learning curve, policy debugging lebih kompleks
ADR-004	Server-side rendering OFF, SPA only	Tim frontend lebih familiar React SPA; SEO tidak relevan (intranet)	Initial load lebih lambat; mitigasi: code splitting + lazy loading

2.3 Risiko dan Asumsi Kritis

ID	Risiko / Asumsi	Dampak	Response / Validasi
R-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
A-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

ID	Risiko / Asumsi	Dampak	Response / Validasi
R-001	Integrasi UIM Next-G tidak stabil / API berubah tanpa notifikasi	Login gagal, seluruh sistem tidak bisa diakses	Mock API untuk parallel dev, integration test di sprint 1, fallback endpoint
R-002	Performa SQL Server menurun pada query kompleks (report/dashboard)	Dashboard timeout, user frustration	Materialized views, Redis cache, query optimization review per sprint
R-003	Tim tidak familiar dengan Casbin RBAC	Delay implementasi authorization, bug permission	Training internal minggu 1, POC sebelum sprint 2, pair programming
A-001	Infrastruktur klien (server, network, K8s) sudah tersedia sebelum SIT	Jika tidak valid: SIT tertunda, deployment terhambat	Validasi di sprint 3, fallback: cloud staging sementara
A-002	UIM Next-G mendukung OAuth 2.0 + JWT sesuai dokumentasi yang diberikan	Jika tidak valid: custom auth layer diperlukan	API exploration sprint 1, validasi dengan tim IT klien
A-003	Data master vendor dan karyawan akan disediakan klien dalam format yang disepakati	Jika tidak valid: delay seeding, modul payment belum bisa ditest	Template format dikirim di kickoff, deadline data sprint 2

---

3. Introduction

DEV BA -- Bagian ini memberikan konteks proyek dari perspektif teknis. Developer yang baru bergabung harus bisa memahami sistem dari bagian ini.

3.1 Tujuan Dokumen

[ISI DI SINI -- Jelaskan tujuan spesifik dokumen ini dalam konteks proyek. Contoh: "Dokumen ini mendeskripsikan arsitektur dan desain teknis Sistem Manajemen Dokumen (SMD) yang akan dikembangkan untuk PT. Tristar Surya Gemilang. SDD ini mendukung implementasi, pengujian, deployment, dan pemeliharaan untuk Release 1.0."]

3.2 Ruang Lingkup Sistem

[ISI DI SINI -- Deskripsikan batasan sistem secara teknis: apa yang termasuk dan tidak termasuk dalam desain ini.]

Aspek	In Scope	Out of Scope
Modul/Service	[ISI DI SINI]	[ISI DI SINI]
Integrasi	[ISI DI SINI]	[ISI DI SINI]
Platform	[ISI DI SINI]	[ISI DI SINI]
Data	[ISI DI SINI]	[ISI DI SINI]
Environment	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Aspek	In Scope	Out of Scope
Modul/Service	Auth, Payment, Reporting, Admin, Notification, Audit, File Service	Escrow, integrasi Core Banking, aplikasi mobile
Integrasi	UIM Next-G (SSO), HCS (data karyawan), Email SMTP, MinIO (file)	Core Banking API, DWH (ditunda ke Fase 2)
Platform	Aplikasi web (SPA + REST API)	Aplikasi mobile native (Android/iOS), aplikasi desktop
Data	Data transaksi, master data, audit log, dokumen yang diunggah	Migrasi data historis dari sistem legacy
Environment	Dev, Staging, Production (on-premises K8s)	Setup DR site (Fase 2)

3.3 Audiens dan Cara Membaca

Audiens	Bagian Relevan	Tujuan
Technical Lead / Architect	Semua bagian	Validasi keseluruhan desain
Backend Developer	Bagian 5, 6, 7, 8, 9	Implementasi backend
Frontend Developer	Bagian 5, 6, 9, 10	Implementasi frontend
DevOps / SRE	Bagian 5, 12, 13, 14	Setup infrastructure, deployment, monitoring
Security Reviewer	Bagian 5, 9, 11, 14	Validasi threat model dan kontrol keamanan
QA	Bagian 7, 9, 10, 16	Strategi testing dan traceability
BA / PM	Bagian 2, 3, 4, 16, 17	Validasi kelengkapan requirement dan risiko

3.4 Asumsi, Constraint, dan Dependensi

TIPS: Daftar kondisi teknis, regulasi, budget, jadwal, legacy, vendor, dan organisasi yang mempengaruhi desain.

ID	Tipe	Pernyataan	Owner	Validasi / Due Date	Status
ACD-001	Assumption	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Validated / Pending
ACD-002	Constraint	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	—
ACD-003	Dependency	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Pending

CONTOH:

ID	Tipe	Pernyataan	Owner	Validasi / Due Date	Status
ACD-001	Assumption	UIM Next-G mendukung OAuth 2.0 + JWT sesuai dokumentasi	Tech Lead	Sprint 1 — API exploration	Validated
ACD-002	Constraint	Data tidak boleh disimpan di cloud publik — on-premises only	PM	Kontrak klien	—
ACD-003	Constraint	Tim development maksimal 8 orang (4 BE, 2 FE, 1 DevOps, 1 QA)	PM	Resource planning	—
ACD-004	Dependency	SQL Server lisensi dan DBA disediakan oleh klien	PM	Kickoff meeting	Pending
ACD-005	Dependency	Desain UI/UX (Figma) difinalisasi sebelum sprint 2	UI/UX Lead	Minggu ke-4	Pending

3.5 Stakeholders, Concerns, dan Viewpoints

TIPS: Identifikasi stakeholder arsitektur dan concern mereka untuk memastikan setiap viewpoint dalam SDD menjawab kebutuhan audiens yang tepat.

Stakeholder	Concern Utama	Viewpoint / Bagian SDD yang Relevan
[ISI DI SINI]	[ISI DI SINI -- contoh: Scalability, performance under load]	[ISI DI SINI -- contoh: §5.7, §12.1, §12.2]
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Stakeholder	Concern Utama	Viewpoint / Bagian SDD
Solution Architect	Konsistensi arsitektur, pemisahan tanggung jawab, extensibility	§5 System Architecture, §6 High-Level Design
Backend Developer	Kontrak API, data model, alur business logic, penanganan error	§7 Data Design, §8 API Design, §9 Component Design
Frontend Developer	Struktur komponen, state management, integrasi API	§10 Frontend Architecture, §8.2-8.4
DevOps / SRE	Topologi deployment, scaling, monitoring, recovery	§13 Infrastructure, §14 Observability
Security Reviewer	Threat model, autentikasi, perlindungan data, audit	§11 Security Design
QA Lead	Testability, traceability, kriteria penerimaan	§16 Verification & Traceability
Product Owner	Keselarasan bisnis, cakupan scope, limitasi yang diterima	§2 Executive Summary, §3.2 Scope, §18 Risks

3.6 Definisi dan Akronim

Istilah	Definisi
ADR	Architecture Decision Record -- catatan keputusan arsitektur
DTO	Data Transfer Object -- objek untuk transfer data antar layer
ERD	Entity Relationship Diagram -- diagram relasi antar entitas
NFR	Non-Functional Requirement -- kebutuhan non-fungsional
RBAC	Role-Based Access Control -- kontrol akses berbasis peran
SDD	Software Design Document -- dokumen desain perangkat lunak
SLO	Service Level Objective -- target tingkat layanan
[ISI DI SINI]	[ISI DI SINI]

---

4. Architecture Drivers

DEV BA SEC -- Identifikasi set kecil dari tujuan, kebutuhan, quality attributes, constraint, kebijakan, dan risiko yang secara material membentuk arsitektur. Setiap driver harus terhubung ke setidaknya satu keputusan desain atau ADR.

4.1 Tujuan Bisnis dan Produk

Objective ID	Tujuan	Ukuran Keberhasilan	Dampak ke Arsitektur
OBJ-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Objective ID	Tujuan	Ukuran Keberhasilan	Dampak ke Arsitektur
OBJ-001	Digitalisasi approval pembayaran	Siklus approval < 4 jam (dari 2-4 hari)	Multi-level approval engine, notification service, real-time status
OBJ-002	Real-time financial visibility	Dashboard refresh < 5 detik, data delay < 1 menit	Event-driven aggregation, materialized views, WebSocket/polling
OBJ-003	Audit compliance OJK	100% transaksi audited, zero manual reconciliation	Immutable audit log, append-only storage, hash chain

4.2 Ringkasan Kapabilitas Fungsional

Capability ID	Kapabilitas / Epic	Primary Actor	Owning Component	Prioritas
CAP-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	MUST / SHOULD / MAY

CONTOH:

Capability ID	Kapabilitas / Epic	Primary Actor	Owning Component	Prioritas
CAP-001	Submit & track pengajuan pembayaran	Operator	Payment Module	MUST
CAP-002	Multi-level approval dengan threshold	Approver	Approval Engine	MUST
CAP-003	Dashboard keuangan real-time	Management	Reporting Module	MUST
CAP-004	Manajemen master data (vendor, GL, unit kerja)	Admin	Admin Module	MUST
CAP-005	Export laporan PDF/Excel	Finance Manager	Reporting Module	SHOULD
CAP-006	Integrasi Core Banking (posting jurnal)	System	Integration Layer	MAY (Fase 2)

4.3 Quality Attribute Scenarios

TIPS: Terjemahkan NFR yang samar menjadi skenario quality-attribute yang terukur. Contoh: "Pada 2.000 concurrent session saat jam sibuk, search API harus mengembalikan 95% request valid dalam 800ms dengan CPU utilization di bawah 70%."

QA ID	Atribut	Skenario	Response Measure	Verifikasi
QA-001	Performance	[ISI DI SINI]	p95 <= [ISI DI SINI] ms pada [ISI DI SINI] req/s	Load test
QA-002	Availability	[ISI DI SINI]	Traffic shift dengan <= [ISI DI SINI] detik interupsi	Failover test
QA-003	Security	[ISI DI SINI]	Akses ditolak, di-log, tidak mengekspos detail sensitif	Security test

CONTOH:

QA ID	Atribut	Skenario	Response Measure	Verifikasi
QA-001	Performance	Pada 500 concurrent users saat jam sibuk, submit pengajuan	p95 <= 500ms, CPU < 70%	k6 load test, 10 menit sustained
QA-002	Availability	Database primary down, traffic shift ke replica	Failover <= 30 detik interupsi, zero data loss	Chaos test — kill primary, measure recovery
QA-003	Security	User tanpa permission mencoba akses endpoint /admin	403 Forbidden, event logged, response tidak mengekspos stack trace atau internal detail	DAST scan + manual security test
QA-004	Scalability	Concurrent users naik dari 500 ke 1.000	Auto-scale tambah pod dalam 2 menit, p95 tetap < 800ms	k6 ramp-up test

4.4 Regulatory, Legal, dan Policy Drivers

Driver ID	Regulasi / Kebijakan	Requirement yang Berlaku	Response di Desain	Evidence
REG-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Driver ID	Regulasi / Kebijakan	Requirement yang Berlaku	Response di Desain	Evidence
REG-001	UU PDP No. 27/2022	Data pribadi harus terenkripsi, consent tercatat, breach notification 72 jam	AES-256 at rest, consent table, breach detection alert	§11.5 Data Protection, §11.9 Privacy
REG-002	POJK Manajemen Risiko TI	Audit trail lengkap, penetration testing, business continuity plan	Immutable audit log, annual pentest, DR plan	§11.8 Audit, §12.4 DR
REG-003	Kebijakan Internal Klien	Segregation of duty untuk approval, data on-premises only	Casbin SoD policy, on-prem K8s deployment	§11.4 Authorization, §13.1 Environment

4.5 Architecture Principles dan Guardrails

Principle ID	Prinsip	Aturan / Guardrail	Proses Exception
PR-001	API-first integration	Interface yang dipublikasi HARUS didefinisikan kontraknya dan di-versioning	ADR + Architect approval
PR-002	Least privilege	Setiap identity HARUS menerima permission minimum yang dibutuhkan	Security exception
PR-003	Observable by design	Setiap production service HARUS emit structured log, metrics, traces, dan health status	Ops approval
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

---

5. System Architecture

DEV -- Bagian ini adalah gambaran besar sistem. Semua keputusan di bagian selanjutnya harus konsisten dengan arsitektur yang didefinisikan di sini. Setiap diagram HARUS memiliki judul, scope, legend, versi, dan penjelasan naratif.

5.1 System Context Diagram

TIPS: Diagram konteks menunjukkan sistem sebagai satu kotak dan semua aktor/sistem eksternal yang berinteraksi dengannya. Jangan tampilkan internal classes.

[ISI DI SINI -- Gambarkan atau deskripsikan diagram konteks]

Contoh:
+---------------+     +-------------------+     +---------------+
|  End User     |---->|   Sistem Utama    |<----|  Admin User   |
|  (Browser)    |     |   (Aplikasi)      |     |  (Browser)    |
+---------------+     +---------+---------+     +---------------+
                                |
                       +--------+--------+
                       v        v        v
               +-----------+ +-----+ +----------+
               | Email SMTP| | SSO | | Storage  |
               | (External)| |(Ext)| | (MinIO)  |
               +-----------+ +-----+ +----------+

5.2 Container / Subsystem View

TIPS: Tampilkan unit-unit yang deployable (aplikasi, service, data store) dan relasi antar-mereka. Pastikan nama konsisten dengan component inventory dan deployment view.

[ISI DI SINI -- Container diagram (C4 Level 2 atau equivalent)]

CONTOH:

+------------------+                    +------------------+
|   Browser (SPA)  |-- HTTPS/REST ----->|   Backend API    |
|   React + TS     |<-- JSON ----------|   Go (Fiber)     |
+------------------+                    +--------+---------+
                                                 |
                         +----------+------------+------------+-----------+
                         |          |            |            |           |
                         v          v            v            v           v
                   +---------+ +--------+ +----------+ +---------+ +---------+
                   |SQL Server| | Redis  | |  MinIO   | |  SMTP   | |UIM Next-G|
                   |(Primary  | |(Cache +| |(Object   | |(Email)  | |(SSO/Auth)|
                   | Data)    | |Session)| | Storage) | |         | |          |
                   +---------+ +--------+ +----------+ +---------+ +---------+

Legend:
[Rectangle]  = Deployable container (application / store / external)
-->          = Synchronous call (protocol labeled)

Container	Teknologi	Tanggung Jawab	Port	Owner
Frontend SPA	React 18, Vite	Rendering UI, penanganan form, konsumsi API	8080 (dev) / Nginx static	FE Team
Backend API	Go 1.22, Fiber v2	Business logic, API endpoint, auth middleware	3000	BE Team
SQL Server	SQL Server 2019	Penyimpanan data utama — transaksi, master data, audit	1433	DBA / DevOps
Redis	Redis 7.x	Penyimpanan session, query cache, rate limit counter	6379	DevOps
MinIO	MinIO (latest)	Penyimpanan objek — dokumen yang diunggah, PDF laporan	9000	DevOps
SMTP (External)	Mailhog (dev) / SMTP klien (prod)	Pengiriman notifikasi email	1025 (dev) / 587 (prod)	DevOps
UIM Next-G (External)	OAuth 2.0 + JWT	Autentikasi SSO, validasi token	HTTPS	IT Klien

5.3 Logical / Component View

TIPS: Tampilkan struktur internal untuk service/modul yang kompleks. Pastikan nama konsisten dengan inventory dan interface catalog.

[ISI DI SINI -- Component diagram (C4 Level 3 atau UML Component)]

Contoh (Modular Monolith):
+-----------------------------------------------------+
|                    API Gateway / Router              |
+---------+---------+---------+---------+--------------+
| Module  | Module  | Module  | Module  |  Shared      |
|   Auth  |  User   |  Forum  | Report  |  Services    |
|         | Mgmt    | Teknis  |         | (Email,      |
|         |         |         |         |  Storage,    |
|         |         |         |         |  Audit)      |
+---------+---------+---------+---------+--------------+
|                   Data Access Layer                   |
+-----------------------------------------------------+
|                     Database                         |
+-----------------------------------------------------+

5.4 Runtime / Process View

TIPS: Tampilkan bagaimana sistem beroperasi saat runtime: proses yang berjalan, komunikasi antar-proses, thread pool, dan pemrosesan asynchronous.

[ISI DI SINI -- Runtime / process view diagram]

CONTOH:

Proses Backend API (single binary, multiple goroutines)
+---------------------------------------------------------------+
|  Proses Utama (Go binary)                                     |
|                                                               |
|  +-- HTTP Server (Fiber)                                      |
|  |   +-- Worker Pool (GOMAXPROCS * goroutines)                |
|  |   |   +-- Request goroutine 1 (Handler → Service → Repo)  |
|  |   |   +-- Request goroutine 2                              |
|  |   |   +-- ...                                              |
|  |                                                            |
|  +-- Worker Latar Belakang                                     |
|  |   +-- Audit Logger (buffered channel, tulis batch)         |
|  |   +-- Pengirim Notifikasi (channel, email async)           |
|  |   +-- Cache Invalidator (Redis pub/sub listener)           |
|  |                                                            |
|  +-- Pekerjaan Terjadwal (cron)                               |
|  |   +-- Cek SLA (setiap 30 menit)                            |
|  |   +-- Pembersihan Session (setiap 1 jam)                   |
|  |                                                            |
|  +-- Pool Koneksi                                              |
|      +-- SQL Server pool (maks 50 koneksi)                    |
|      +-- Redis pool (maks 20 koneksi)                         |
+---------------------------------------------------------------+

5.5 Data Architecture View

TIPS: Tampilkan kepemilikan data, aliran data antar-komponen, dan system of record untuk setiap domain data.

[ISI DI SINI -- High-level data flow / data ownership view]

CONTOH:

Peta Kepemilikan Data:

+------------------+     +------------------+     +------------------+
| Payment Module   |     | Admin Module     |     | Auth Service     |
| (Pemilik data:   |     | (Pemilik data:   |     | (Baca dari       |
|  - Payments      |     |  - Vendors       |     |  eksternal:      |
|  - Approvals     |     |  - GL Codes      |     |  - UIM Next-G)   |
|  - Documents)    |     |  - Unit Kerja)   |     |                  |
+--------+---------+     +--------+---------+     | Milik lokal:     |
         |                        |               |  - Sessions      |
         v                        v               |  - Casbin Policy)|
   +-----+------------------------+------------+--+--------+--------+
   |                    SQL Server (DB Utama)                       |
   +-----+---------------------------------------------------------+
         |
         v (async, post-commit)
   +-----+--------+     +------------------+
   | Audit Service |     | MinIO            |
   | (Pemilik data:|     | (Pemilik data:   |
   |  - Audit Log) |     |  - File/Dokumen) |
   +---------------+     +------------------+

5.6 Security and Trust Boundary View

TIPS: Tampilkan trust boundary, aset sensitif, dan aliran data yang melewati boundary. Digunakan sebagai dasar threat modeling.

[ISI DI SINI -- Trust boundary / security data flow diagram]

CONTOH:

Trust Boundaries:

╔══════════════════════════════════════════════════════════════════╗
║  UNTRUSTED ZONE (Internet / User Device)                       ║
║  +------------------+                                          ║
║  | Browser (User)   | ── user input (untrusted) ──┐           ║
║  +------------------+                              │           ║
╠═════════════════════════════════════════════════════╪═══════════╣
║  DMZ (Reverse Proxy)                               │           ║
║  +------------------+                              │           ║
║  | Nginx            | ◄─ HTTPS/TLS 1.3 ───────────┘           ║
║  | (WAF, rate limit)|                                          ║
║  +--------+---------+                                          ║
╠═══════════╪════════════════════════════════════════════════════╣
║  TRUSTED ZONE (Internal Network)                    │          ║
║           │                                                    ║
║  +--------v---------+     +---------+     +----------+        ║
║  | Backend API      |────>| Redis   |     | MinIO    |        ║
║  | (Auth middleware, |     | (Session|     | (Files)  |        ║
║  |  Casbin RBAC)    |     |  Cache) |     +----------+        ║
║  +--------+---------+     +---------+                         ║
║           │                                                    ║
║  +--------v---------+     +---------+                         ║
║  | SQL Server       |     | Audit DB|                         ║
║  | (Encrypted PII)  |     |(Append  |                         ║
║  +------------------+     | Only)   |                         ║
║                           +---------+                         ║
╠════════════════════════════════════════════════════════════════╣
║  EXTERNAL ZONE (Third-party)                                   ║
║  +------------------+     +------------------+                 ║
║  | UIM Next-G (SSO) |     | SMTP (Email)     |                ║
║  | ◄── HTTPS ──────────── Backend API ────────►               ║
║  +------------------+     +------------------+                 ║
╚════════════════════════════════════════════════════════════════╝

Aset Sensitif: PII di SQL Server (terenkripsi), JWT token (httpOnly cookie),
Casbin policy, audit log (immutable), dokumen yang diunggah (MinIO, terenkripsi at rest)

5.7 Architecture Style dan Rationale

Pola Arsitektur: [ISI DI SINI -- contoh: Monolith / Modular Monolith / Microservices / Serverless / Event-Driven]

Gaya yang Dipilih	Alasan Pemilihan	Alternatif yang Dipertimbangkan	Trade-off
[ISI DI SINI]	[ISI DI SINI -- hubungkan ke driver]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Gaya yang Dipilih	Alasan Pemilihan	Alternatif yang Dipertimbangkan	Trade-off
Modular Monolith (Clean Architecture)	Tim kecil (8 dev), deployment sederhana, shared DB mengurangi kompleksitas. Mendukung OBJ-001 (digitalisasi) tanpa overhead microservices.	Microservices: independent scaling per modul tapi overhead infra + observability terlalu tinggi untuk tim 8 orang. Monolith tanpa modularity: lebih cepat tapi sulit di-scale dan di-maintain.	Scaling terbatas per-modul (mitigasi: K8s HPA per replica set). Refactor ke microservices jika volume > 50K txn/hari.

5.8 Technology Stack

5.8.1 Backend

Layer	Teknologi	Versi	Tujuan	Alasan Pemilihan
Bahasa	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Framework	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Database	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Cache	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Message Queue	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Object Storage	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Identity	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Observability	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Layer	Teknologi	Versi	Tujuan	Alasan Pemilihan
Bahasa	Go	1.22+	Backend language	Performa tinggi, concurrency native, static binary, tim sudah berpengalaman
Framework	Fiber (v2)	2.52+	HTTP framework	Express-like API, performa tinggi (fasthttp), middleware ecosystem
Database	SQL Server	2019+	Primary data store	Klien sudah memiliki lisensi dan DBA; mendukung transaction isolation dan JSON
Cache	Redis	7.x	Session store, query cache	In-memory, pub/sub untuk invalidation, cluster-ready
Message Queue	— (Fase 1)	—	Async processing	Fase 1: goroutine-based async. Fase 2: RabbitMQ/NATS jika volume meningkat
Object Storage	MinIO	latest	File/document storage	S3-compatible, on-premises, no cloud dependency
Identity	UIM Next-G (external)	—	SSO, authentication	Klien's existing identity provider; OAuth 2.0 + JWT
Observability	ELK Stack + Prometheus	—	Logging + metrics	Centralized logging (ELK), metrics/alerting (Prometheus + Grafana)

5.8.2 Frontend

Layer	Teknologi	Versi	Tujuan	Alasan Pemilihan
Framework	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
State Management	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
UI Library	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
HTTP Client	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Build Tool	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Layer	Teknologi	Versi	Tujuan	Alasan Pemilihan
Framework	React	18.x	UI framework	Component-based, ecosystem matang, tim berpengalaman
State Management	React Query + Zustand	5.x / 4.x	Server state + client state	React Query untuk API caching/sync; Zustand untuk UI state minimal
UI Library	shadcn/ui + Tailwind CSS	latest	Component library + styling	Customizable, accessible, utility-first CSS
HTTP Client	Axios	1.x	API calls	Interceptors untuk auth token, timeout, retry
Build Tool	Vite	5.x	Build & dev server	HMR cepat, ESBuild-based, tree-shaking

5.8.3 Infrastructure

Layer	Teknologi	Versi	Tujuan	Keterangan
Server / Cloud	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Container	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Reverse Proxy	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
CI/CD	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Monitoring	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Layer	Teknologi	Versi	Tujuan	Keterangan
Server	On-premises (VM)	—	Application hosting	Klien requirement: data tidak boleh di cloud publik
Container	Docker + Kubernetes	1.28+	Orchestration, scaling	HPA untuk auto-scale, rolling update zero-downtime
Reverse Proxy	Nginx	1.25+	SSL termination, routing, rate limiting	Reverse proxy + static file serving untuk FE
CI/CD	GitLab CI	—	Build, test, deploy pipeline	Self-hosted GitLab, Docker-in-Docker runners
Monitoring	Prometheus + Grafana	—	Metrics, alerting, dashboards	Prometheus scrape, Grafana visualization, AlertManager

5.9 Architecture Decision Records (ADR)

TIPS: Setiap keputusan arsitektur signifikan harus dicatat. ADR membantu tim memahami MENGAPA suatu keputusan dibuat, bukan hanya APA yang diputuskan.

ADR Index

ADR ID	Judul	Status	Tanggal	Lokasi
ADR-001	[ISI DI SINI]	Proposed / Accepted / Superseded	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

ADR ID	Judul	Status	Tanggal	Lokasi
ADR-001	Modular Monolith over Microservices	Accepted	15/01/2026	§5.9 / /docs/adr/001-modular-monolith.md
ADR-002	SQL Server over PostgreSQL	Accepted	15/01/2026	§5.9 / /docs/adr/002-sql-server.md
ADR-003	Casbin RBAC over custom permission	Accepted	20/01/2026	§5.9 / /docs/adr/003-casbin-rbac.md
ADR-004	SPA only, no SSR	Accepted	20/01/2026	§5.9 / /docs/adr/004-spa-no-ssr.md
ADR-005	Goroutine async over message queue (Fase 1)	Accepted	22/01/2026	§5.9 / /docs/adr/005-goroutine-async.md

ADR-001: [ISI DI SINI -- Judul Keputusan]

Aspek	Detail
Status	Proposed / Accepted / Deprecated / Superseded / Rejected
Tanggal	[ISI DI SINI]
Konteks	[ISI DI SINI -- Masalah, driver, dan constraint yang memerlukan keputusan]
Keputusan	[ISI DI SINI -- Keputusan yang diambil]
Opsi yang Dipertimbangkan	[ISI DI SINI -- Opsi lain dan evaluasinya]
Konsekuensi	[ISI DI SINI -- Positif, negatif, risiko, dan follow-up]
Dampak Compliance / Security	[ISI DI SINI -- Dampak terhadap kepatuhan dan keamanan]
Diputuskan Oleh	[ISI DI SINI]
Supersedes / Superseded By	[ISI DI SINI -- ADR ID terkait, jika ada]

[Tambahkan ADR sesuai kebutuhan.]

CONTOH:

ADR-001: Modular Monolith over Microservices

Aspek	Detail
Status	Accepted
Tanggal	15/01/2026
Konteks	Tim 8 developer, timeline 6 bulan, klien belum punya container orchestration matang. Perlu arsitektur yang scalable tapi deployable sederhana.
Keputusan	Modular Monolith dengan Clean Architecture (Handler → Service → Repository). Setiap modul memiliki boundary yang jelas, tapi di-deploy sebagai satu binary.
Opsi yang Dipertimbangkan	(1) Pure Microservices: independent scaling, independent deploy. Ditolak: overhead infra terlalu tinggi untuk tim kecil, observability kompleks. (2) Monolith tanpa modularity: lebih cepat tapi sulit dimaintain dan di-refactor.
Konsekuensi	(+) Deploy sederhana, shared DB, debugging lebih mudah. (-) Scaling per-modul tidak bisa independen. (-) Harus refactor jika volume > 50K txn/hari.
Dampak Compliance / Security	Tidak ada dampak negatif — security controls (auth, RBAC, audit) tetap bisa diterapkan di module boundary.
Diputuskan Oleh	Tech Lead + Architect
Supersedes / Superseded By	—

---

6. High-Level Design

DEV -- Bagian ini mendeskripsikan bagaimana sistem dipecah menjadi komponen/modul dan bagaimana mereka berinteraksi.

6.1 Component Inventory

Component ID	Nama	Tipe	Owner	Tanggung Jawab Utama	Criticality
CMP-001	[ISI DI SINI]	Service / Module / Job / Client	[ISI DI SINI]	[ISI DI SINI]	H / M / L
CMP-002	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Component ID	Nama	Tipe	Owner	Tanggung Jawab Utama	Criticality
CMP-001	Auth Service	Module	Backend Team	Login, logout, refresh token, manajemen session	H
CMP-002	Payment Module	Module	Backend Team	Pengajuan, approval workflow, pencairan	H
CMP-003	Reporting Module	Module	Backend Team	Agregasi dashboard, pembuatan laporan, export PDF	H
CMP-004	Admin Module	Module	Backend Team	CRUD master data, manajemen user, penugasan role	M
CMP-005	Notification Service	Shared Service	Backend Team	Notifikasi email, notifikasi in-app	M
CMP-006	Audit Service	Shared Service	Backend Team	Pencatatan audit immutable, query audit trail	H
CMP-007	File Service	Shared Service	Backend Team	Upload, download, scan virus, integrasi MinIO	M
CMP-008	Frontend SPA	Client	Frontend Team	Rendering UI, penanganan form, konsumsi API	H

6.2 Dependency Matrix

Consumer	Provider	Tipe Dependensi	Startup Required	Efek Kegagalan	Fallback
[ISI DI SINI]	[ISI DI SINI]	Sync / Async / Data / Library	Y/N	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Consumer	Provider	Tipe Dependensi	Startup Required	Efek Kegagalan	Fallback
Payment Module	Auth Service	Sync (middleware)	Ya	Semua request gagal 401	— (blocking)
Payment Module	Notification Service	Async (goroutine)	Tidak	Notifikasi tidak terkirim	Antrikan + retry 3x
Payment Module	Audit Service	Async (goroutine)	Tidak	Audit log tertunda	Buffer + tulis batch
Reporting Module	Database	Sync (query)	Ya	Dashboard kosong	Sajikan cache stale 5 menit
Auth Service	UIM Next-G (eksternal)	Sync (HTTP)	Ya	Login tidak bisa	— (blocking, kritis)
File Service	MinIO (eksternal)	Sync (S3 API)	Tidak	Upload/download gagal	Pesan error + retry
Frontend SPA	Backend API	Sync (HTTP)	Ya	UI tidak berfungsi	Tampilan error + indikator offline

6.3 Layer Architecture

TIPS: Definisikan layer dan aturan dependensi antar-layer. Aturan ini harus dipatuhi selama implementasi.

Layer	Tanggung Jawab	Boleh Mengakses	Tidak Boleh Mengakses
Presentation (Handler/Controller)	Parsing request, response formatting	Service	Repository, Database langsung
Service (Business Logic)	Validasi bisnis, orkestrasi	Repository, Helper	Database langsung, HTTP framework
Repository (Data Access)	Query database, mapping data	Database	Service, Handler
Domain (Entity/Model)	Definisi struktur data	--	Semua (entity adalah data, bukan logic)

Aturan Dependensi:

• Dependensi mengalir satu arah: Presentation -> Service -> Repository -> Database
• Layer yang lebih tinggi TIDAK BOLEH diimpor oleh layer yang lebih rendah
• Shared utilities (helper, constants) boleh diakses oleh semua layer
• Cross-module communication: melalui service layer, BUKAN langsung ke repository module lain

6.4 Cross-Cutting Concerns

Aspek yang melintas semua module/layer:

Concern	Pendekatan	Implementasi
Authentication	[ISI DI SINI -- contoh: Middleware JWT]	[ISI DI SINI]
Authorization	[ISI DI SINI -- contoh: Casbin RBAC]	[ISI DI SINI]
Logging	[ISI DI SINI -- contoh: Structured JSON log]	[ISI DI SINI]
Error Handling	[ISI DI SINI -- contoh: Centralized error response]	[ISI DI SINI]
Validation	[ISI DI SINI -- contoh: DTO validation + business rule]	[ISI DI SINI]
Audit Trail	[ISI DI SINI -- contoh: Async goroutine post-commit]	[ISI DI SINI]
Caching	[ISI DI SINI -- contoh: Redis/in-memory per endpoint]	[ISI DI SINI]
Correlation/Tracing	[ISI DI SINI -- contoh: X-Correlation-ID header propagation]	[ISI DI SINI]

CONTOH:

Concern	Pendekatan	Implementasi
Authentication	JWT middleware — validasi token di setiap request	middleware/auth.go — ekstrak token dari httpOnly cookie, verifikasi dengan UIM public key
Authorization	Casbin RBAC — policy-as-config, diterapkan di level handler	middleware/casbin.go — cek (user, resource, action) sebelum handler dieksekusi
Logging	Structured JSON log dengan correlation ID	pkg/logger/logger.go — zerolog, auto-inject request_id, user_id, latency
Error Handling	ErrorHandler terpusat di konfigurasi Fiber	main.go ErrorHandler — 4xx diteruskan, 5xx disanitasi + di-log, format RFC 9457
Validation	Validasi DTO (struct tags) + validasi business rule (service layer)	Handler: validator.Struct(dto). Service: pengecekan business rule
Audit Trail	Async goroutine post-commit — fire-and-forget dengan retry	pkg/audit/audit.go — buffered channel, tulis batch setiap 5 detik atau 100 event
Caching	Redis — cache per-endpoint dengan invalidasi saat mutasi	pkg/cache/cache.go — cache key = {module}:{entity}:{id}, TTL 5 menit, invalidasi saat CUD
Correlation/Tracing	Header X-Correlation-ID — di-generate jika belum ada, dipropagasi ke semua panggilan downstream	Middleware generate UUID, inject ke context, semua log/panggilan eksternal menyertakannya

---

7. Data Design

DEV BA -- Data model adalah fondasi sistem. Perubahan di sini berdampak luas. Review dengan teliti.

7.1 Data Domain dan Ownership

Data Domain	System of Record	Owner	Steward	Consumers	Classification
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Data Domain	System of Record	Owner	Steward	Consumers	Classification
Payment Transactions	Payment Module (DB)	Finance	Tech Lead	Reporting, Audit, DWH	Confidential
Employee Data	HCS (external)	HR	IT Klien	Auth, Payment (lookup)	Restricted
Master Data (Vendor, GL)	Admin Module (DB)	Finance	BA	Payment, Reporting	Internal
Audit Logs	Audit Service (DB)	Compliance	Security Lead	Auditor, Security	Restricted
Uploaded Documents	MinIO (object store)	Finance	DevOps	Payment, Reporting	Confidential

7.2 Entity Relationship Diagram

[ISI DI SINI -- Sertakan ERD (link ke diagram tool, Mermaid syntax, atau deskripsi tekstual). ERD harus mencakup seluruh entitas utama dan relasinya.]

Contoh (Mermaid syntax):
erDiagram
    User ||--o{ Document : creates
    User ||--o{ Permission : has
    Document ||--o{ DocumentVersion : has
    Document }o--|| Category : belongs_to

7.3 Physical Data Model

TIPS: Untuk setiap tabel, dokumentasikan: nama kolom, tipe data, constraint, dan keterangan. Ini menjadi referensi utama saat development.

7.3.1 [ISI DI SINI -- Nama Tabel 1]

Tujuan: [ISI DI SINI] Estimated Volume: [ISI DI SINI -- jumlah rows / growth rate] Partitioning: [ISI DI SINI -- strategy jika diperlukan]

Kolom	Tipe Data	Nullable	Default	Constraint	Keterangan
Id	UNIQUEIDENTIFIER	NO	NEWID()	PK	Primary key
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
CreatedAt	DATETIME2	NO	SYSDATETIME()	--	Waktu pembuatan
CreatedBy	UNIQUEIDENTIFIER	NO	--	FK -> User.Id	Pembuat record
UpdatedAt	DATETIME2	YES	NULL	--	Waktu terakhir diubah
UpdatedBy	UNIQUEIDENTIFIER	YES	NULL	FK -> User.Id	Pengubah terakhir
DeletedAt	DATETIME2	YES	NULL	--	Soft delete marker

Index:

Nama Index	Kolom	Tipe	Keterangan
IX_[Tabel]_[Kolom]	[ISI DI SINI]	Non-clustered	[ISI DI SINI]
UQ_[Tabel]_[Kolom]	[ISI DI SINI]	Unique	[ISI DI SINI]

[Ulangi untuk setiap tabel.]

CONTOH:

7.3.1 Payments

Tujuan: Menyimpan data pengajuan pembayaran operasional Estimated Volume: 10.000 rows/tahun, ~50 rows/hari kerja, growth 30%/tahun Partitioning: Tidak diperlukan di Fase 1 (volume < 100K). Evaluasi partitioning by CreatedAt jika > 500K rows.

Kolom	Tipe Data	Nullable	Default	Constraint	Keterangan
Id	UNIQUEIDENTIFIER	NO	NEWID()	PK	Primary key
NomorPengajuan	VARCHAR(20)	NO	—	UNIQUE	Format: PAY-[UNIT]-[YYYY]-[NNNN]
PemohonId	UNIQUEIDENTIFIER	NO	—	FK → Users.Id	User yang membuat pengajuan
VendorId	UNIQUEIDENTIFIER	NO	—	FK → Vendors.Id	Vendor penerima pembayaran
Nominal	DECIMAL(15,2)	NO	—	CHECK > 0	Dalam IDR
Kategori	VARCHAR(50)	NO	—	—	Kategori biaya (Operasional, Perjalanan Dinas, dll.)
Status	VARCHAR(20)	NO	'Draft'	—	Draft / Submitted / Approved / Rejected / Paid / Cancelled
TanggalJatuhTempo	DATE	NO	—	—	Batas waktu pembayaran
CreatedAt	DATETIME2	NO	SYSDATETIME()	—	Waktu pembuatan
CreatedBy	UNIQUEIDENTIFIER	NO	—	FK → Users.Id	Pembuat record
UpdatedAt	DATETIME2	YES	NULL	—	Waktu terakhir diubah
DeletedAt	DATETIME2	YES	NULL	—	Soft delete marker

Index:

Nama Index	Kolom	Tipe	Keterangan
IX_Payments_Status_CreatedAt	Status, CreatedAt DESC	Non-clustered	List query: filter by status, sort by newest
IX_Payments_PemohonId	PemohonId	Non-clustered	"Pengajuan Saya" query
IX_Payments_VendorId	VendorId	Non-clustered	Lookup by vendor
UQ_Payments_NomorPengajuan	NomorPengajuan	Unique	Enforce uniqueness

7.4 Data Dictionary

TIPS: Berikan definisi bisnis untuk setiap field penting. Field tanpa definisi menyebabkan asumsi yang berbeda di tim.

Entity.Field	Tipe / Length	Required	Definisi Bisnis	Validasi / Domain	Sensitif
[ISI DI SINI]	[ISI DI SINI]	Y/N	[ISI DI SINI]	[ISI DI SINI]	Y/N + Class

CONTOH:

Entity.Field	Tipe / Length	Required	Definisi Bisnis	Validasi / Domain	Sensitif
Payment.NomorPengajuan	VARCHAR(20)	Y	Nomor unik pengajuan, auto-generated format PAY-[UNIT]-[YYYY]-[NNNN]	Unique, auto-increment per tahun per unit	N
Payment.Nominal	DECIMAL(15,2)	Y	Jumlah pembayaran yang diajukan dalam IDR	> 0, max 999.999.999.999,99. Tidak boleh > sisa anggaran	N
Payment.Status	VARCHAR(20)	Y	Status lifecycle pengajuan	Domain: Draft, Submitted, Approved, Rejected, Paid, Cancelled	N
Vendor.NPWP	VARCHAR(20)	Y	Nomor Pokok Wajib Pajak vendor	Format 15 digit, validasi check digit	Y (PII)
User.Email	VARCHAR(255)	Y	Alamat email karyawan, digunakan untuk login dan notifikasi	RFC 5322 format, unique	Y (PII)
AuditLog.OldValue	NVARCHAR(MAX)	N	Snapshot data sebelum perubahan (JSON)	JSON valid	Y (may contain PII)

7.5 Data Integrity, Transaksi, dan Concurrency

Concern	Keputusan Desain
Transaction boundaries	[ISI DI SINI -- Unit of work / distributed transaction avoidance]
Referential integrity	[ISI DI SINI -- Database constraints / application enforcement]
Optimistic / pessimistic concurrency	[ISI DI SINI -- Strategy + version field / lock]
Idempotency	[ISI DI SINI -- Key / unique constraint / deduplication window]
Consistency model	[ISI DI SINI -- Strong / eventual / read-your-writes]
Time handling	[ISI DI SINI -- UTC storage, timezone display, clock source]

CONTOH:

Concern	Keputusan Desain
Transaction boundaries	Satu transaksi per HTTP request (unit of work pattern). Distributed transaction dihindari — gunakan saga/compensating action jika lintas service.
Referential integrity	FK constraint di database level untuk data kritis (User, Payment). Application-level check untuk soft-reference (audit log ke entity).
Optimistic concurrency	UpdatedAt field sebagai version — UPDATE WHERE UpdatedAt = @expected. 409 Conflict jika stale.
Idempotency	POST /payments: Idempotency-Key header (UUID), dedup window 24 jam, stored in Redis.
Consistency model	Strong consistency untuk transactional data (ACID). Eventual consistency untuk audit log dan notification (async goroutine).
Time handling	UTC storage di semua kolom DATETIME2. Display di frontend dalam WIB (UTC+7). Server clock sync via NTP.

7.6 Data Flow

TIPS: Dokumentasikan bagaimana data mengalir melalui sistem untuk flow utama.

Flow: [ISI DI SINI -- Nama Flow, contoh: "Create Document"]

User Input (Browser)
    |
    v
Frontend (Form -> API call)
    |  Body: { title, category, files[] }
    v
Backend Handler (Parse + Validate)
    |
    v
Service (Business Logic)
    |  - Generate UUID
    |  - Validate permission
    |  - Begin transaction
    v
Repository (SQL Insert)
    |  INSERT INTO Document (Id, Title, ...)
    v
Database (Persist)
    |
    v (post-commit)
Side Effects
    +-- Notification (async)
    +-- Audit Trail (async)
    +-- File Upload to Storage (sync within tx)

7.7 Data Migration dan Conversion

Object	Source	Target	Transformation	Validasi / Rekonsiliasi	Rollback / Re-run
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Object	Source	Target	Transformation	Validasi / Rekonsiliasi	Rollback / Re-run
Master Vendor	CSV export dari sistem legacy	Vendors table (SQL Server)	Map legacy vendor_code → UUID, normalize NPWP format, trim whitespace	Row count match, NPWP format validation, no duplicate names	Truncate + re-import (idempotent, no FK dependents at migration time)
Master GL Codes	Excel dari Finance	GLCodes table	Map legacy GL number → new format, validate against chart of accounts	Row count + GL sum validation	Truncate + re-import
User accounts	HCS API (employee data)	Users table	Map NIP → UserId, extract KodeUnitKerja, assign default role (Operator)	NIP uniqueness check, unit kerja exists in SPGUnitOrganisasi	Soft delete all + re-sync (preserves audit trail)
Historical transactions	Not migrated (Fase 1)	—	—	—	N/A — legacy system remains accessible for historical queries

Aturan Migrasi:

• Setiap perubahan schema dalam bentuk migration file bernomor urut
• Migration yang sudah di-apply di production TIDAK BOLEH diubah
• Rollback script wajib di-test di staging sebelum apply ke production
• Data migration (transform data) terpisah dari schema migration (alter table)
• Tools: [ISI DI SINI -- contoh: Manual SQL scripts / Flyway / golang-migrate]
• Naming: [ISI DI SINI -- contoh: YYYYMMDD_HHMMSS_description.sql]

7.8 Data Lifecycle, Retention, dan Disposal

Data Set	Sumber	Retensi Aktif	Archive	Deletion / Anonymization	Legal Hold
Transactional data	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Audit logs	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
User data	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Uploaded files	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Data Set	Sumber	Retensi Aktif	Archive	Deletion / Anonymization	Legal Hold
Payment transactions	Payment Module	2 tahun	Cold storage 5 tahun	Hapus setelah 7 tahun	Suspend deletion jika ada audit/litigasi aktif
Audit logs	Audit Service	3 tahun (Elasticsearch)	S3/MinIO cold 5 tahun	Hapus setelah 8 tahun	Tidak boleh dihapus selama legal hold
User data (PII)	Auth + HCS sync	Selama akun aktif	1 tahun setelah nonaktif	Anonymize setelah 2 tahun nonaktif (UU PDP)	Suspend jika data subject request pending
Uploaded files	MinIO	2 tahun	Compressed archive 5 tahun	Hapus setelah 7 tahun	Ikut parent transaction hold

7.9 Cache, Search, dan Derived Data

Store	Data	Source of Truth	TTL / Refresh	Invalidation	Consistency Risk
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Store	Data	Source of Truth	TTL / Refresh	Invalidation	Consistency Risk
Redis (query cache)	Daftar payment per unit kerja	SQL Server (tabel Payment)	TTL 5 menit	Invalidasi saat CREATE/UPDATE/DELETE payment	Data basi hingga 5 menit — dapat diterima untuk tampilan daftar
Redis (session)	Session user + JWT claims	UIM Next-G (token)	15 menit (access), 7 hari (refresh)	Invalidasi saat logout, ganti password, ganti role	Session valid hingga TTL habis meskipun dicabut di IdP — mitigasi: TTL pendek
In-memory (lookup)	Master data (vendor, kode GL)	SQL Server (MasterData)	30 menit, refresh saat startup	Reload penuh saat admin update	Basi hingga 30 menit — dapat diterima untuk data referensi

---

8. API & Interface Design

DEV QA -- API contract adalah perjanjian antara frontend dan backend serta antar-service. Perubahan HARUS dikomunikasikan dan disetujui semua pihak.

8.1 API Standards

Aspek	Standar
Style	[ISI DI SINI -- REST / GraphQL / gRPC]
Versioning	[ISI DI SINI -- contoh: URL path /api/v1/]
Authentication	[ISI DI SINI -- contoh: JWT in httpOnly cookie]
Authorization	[ISI DI SINI -- contoh: Scope / Role / Policy]
Content-Type	[ISI DI SINI -- contoh: application/json]
Naming	[ISI DI SINI -- contoh: kebab-case, plural nouns]
Correlation	[ISI DI SINI -- contoh: X-Correlation-ID / traceparent]
Idempotency	[ISI DI SINI -- aturan untuk mutating operations]
Error Model	[ISI DI SINI -- contoh: RFC 9457 Problem Details / custom standard]
Rate Limiting	[ISI DI SINI -- limits, headers, 429 behavior]
Timeout	[ISI DI SINI -- client dan server timeout]

CONTOH:

Aspek	Standar
Style	RESTful (resource-oriented), payload JSON
Versioning	URL path: /api/v1/payments, /api/v2/payments
Authentication	JWT di httpOnly cookie (access token 15 menit, refresh 7 hari)
Authorization	Casbin RBAC — middleware cek (user, resource, action) sebelum handler
Content-Type	application/json (request + response), multipart/form-data (upload file)
Naming	URL kebab-case (/api/v1/payment-requests), field JSON camelCase
Correlation	Header X-Correlation-ID — di-generate oleh Nginx jika belum ada, dipropagasi ke semua service
Idempotency	Mutasi POST: header Idempotency-Key (UUID), deduplikasi via Redis (jendela 24 jam)
Error Model	Standar custom (lihat §8.2): { success, error: { code, message, details[] } }
Rate Limiting	100 req/menit per user (API key), 1000 req/menit per IP. Respons 429 dengan header Retry-After
Timeout	Client: 10 dtk default, 30 dtk untuk laporan. Server: 30 dtk request timeout, 60 dtk untuk upload file

8.2 Standard Response Format

Success (single resource):

{
  "success": true,
  "data": { ... }
}

Success (collection with pagination):

{
  "success": true,
  "data": [ ... ],
  "meta": {
    "page": 1,
    "perPage": 10,
    "total": 100,
    "totalPages": 10
  }
}

Error:

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Deskripsi error yang user-friendly",
    "details": [
      { "field": "email", "message": "Format email tidak valid" }
    ]
  }
}

8.3 Endpoint Inventory

TIPS: Daftar semua endpoint yang akan dibangun. Detail per-endpoint (request/response body) didokumentasikan di section 8.4 atau di API documentation tool (Swagger/Postman).

Module: [ISI DI SINI]

Method	Endpoint	Deskripsi	Auth	Permission	Performance Target
GET	/api/v1/[resource]	List all	Yes	read	[ISI DI SINI]
GET	/api/v1/[resource]/:id	Get by ID	Yes	read	[ISI DI SINI]
POST	/api/v1/[resource]	Create	Yes	create	[ISI DI SINI]
PUT	/api/v1/[resource]/:id	Update	Yes	update	[ISI DI SINI]
DELETE	/api/v1/[resource]/:id	Delete (soft)	Yes	delete	[ISI DI SINI]

[Ulangi untuk setiap module.]

CONTOH:

Module: Payment

Method	Endpoint	Deskripsi	Auth	Permission	Performance Target
GET	/api/v1/payments	List pengajuan (filter, pagination)	Yes	payment:read	p95 < 500ms
GET	/api/v1/payments/:id	Detail pengajuan + approval history	Yes	payment:read	p95 < 300ms
POST	/api/v1/payments	Submit pengajuan baru	Yes	payment:create	p95 < 500ms
PUT	/api/v1/payments/:id	Update draft pengajuan	Yes	payment:update	p95 < 500ms
DELETE	/api/v1/payments/:id	Cancel pengajuan (soft delete)	Yes	payment:delete	p95 < 300ms
POST	/api/v1/payments/:id/approve	Approve pengajuan	Yes	payment:approve	p95 < 400ms
POST	/api/v1/payments/:id/reject	Reject pengajuan	Yes	payment:approve	p95 < 400ms

Module: Admin

Method	Endpoint	Deskripsi	Auth	Permission	Performance Target
GET	/api/v1/vendors	List vendor aktif	Yes	admin:read	p95 < 300ms
POST	/api/v1/vendors	Create vendor baru	Yes	admin:create	p95 < 300ms
GET	/api/v1/users	List users + roles	Yes	admin:user	p95 < 300ms
PUT	/api/v1/users/:id/role	Assign/change role	Yes	admin:user	p95 < 300ms

8.4 API Contract Detail

TIPS: Untuk setiap endpoint yang kompleks, dokumentasikan contract detail di sini. Endpoint sederhana (CRUD standar) cukup di inventory di atas.

[METHOD] /api/v1/[endpoint]

Field	Specification
Operation ID	[ISI DI SINI]
Purpose	[ISI DI SINI]
Caller(s)	[ISI DI SINI]
Authorization	[ISI DI SINI]
Idempotency	[ISI DI SINI]
Transaction Boundary	[ISI DI SINI]
Side Effects / Events	[ISI DI SINI]
Performance Target	[ISI DI SINI]

Request:

Parameter	Lokasi	Tipe	Required	Validasi	Keterangan
[ISI DI SINI]	body/path/query/header	[ISI DI SINI]	Yes/No	[ISI DI SINI]	[ISI DI SINI]

Response Success (200/201):

{
  "success": true,
  "data": {
    "[field]": "[type] -- [keterangan]"
  }
}

Response Error:

Kondisi	HTTP Code	Error Code	Message
[ISI DI SINI]	400	VALIDATION_ERROR	[ISI DI SINI]
[ISI DI SINI]	403	FORBIDDEN	[ISI DI SINI]
[ISI DI SINI]	404	NOT_FOUND	[ISI DI SINI]
[ISI DI SINI]	409	CONFLICT	[ISI DI SINI]
[ISI DI SINI]	429	RATE_LIMITED	[ISI DI SINI]
[ISI DI SINI]	503	SERVICE_UNAVAILABLE	[ISI DI SINI]

CONTOH:

POST /api/v1/payments

Field	Specification
Operation ID	createPayment
Purpose	Submit pengajuan pembayaran operasional baru
Caller(s)	Frontend SPA (halaman PaymentCreate)
Authorization	Role: Operator. Casbin check: (user, payment, create)
Idempotency	Header Idempotency-Key (UUID). Deduplikasi via Redis, jendela 24 jam. Duplikat mengembalikan 200 dengan payment yang sudah ada.
Transaction Boundary	Satu transaksi DB: insert Payment + insert DocumentAttachment. Upload file ke MinIO di luar transaksi.
Side Effects / Events	Post-commit async: (1) Email notifikasi ke Approver L1, (2) Entri audit log
Performance Target	p95 < 500ms

Request:

Parameter	Lokasi	Tipe	Required	Validasi	Keterangan
vendorId	body	UUID	Ya	Harus ada di tabel Vendors (aktif)	Vendor penerima
nominal	body	number	Ya	> 0, maks 999999999999.99	Dalam IDR
kategori	body	string	Ya	Enum: Operasional, PerjalananDinas, Lainnya	Kategori biaya
tanggalJatuhTempo	body	date (YYYY-MM-DD)	Ya	>= hari ini + 3 hari	Batas waktu
keterangan	body	string	Tidak	Maks 500 karakter	Catatan tambahan
files	body	File[]	Ya	PDF/JPG/PNG, maks 10MB per file, maks 5 file	Dokumen pendukung
Idempotency-Key	header	UUID	Ya	Format UUID valid	Kunci deduplikasi

Response Success (201):

{
  "success": true,
  "data": {
    "id": "uuid",
    "nomorPengajuan": "PAY-PKU-2026-0042",
    "status": "Submitted",
    "createdAt": "2026-08-08T12:00:00Z"
  }
}

Response Error:

Kondisi	HTTP Code	Error Code	Message
Nominal > sisa anggaran	400	BUDGET_EXCEEDED	"Nominal melebihi sisa anggaran (sisa: Rp 50.000.000)"
User tidak punya permission create	403	FORBIDDEN	"Anda tidak memiliki akses untuk membuat pengajuan"
Vendor tidak ditemukan / nonaktif	404	VENDOR_NOT_FOUND	"Vendor tidak ditemukan atau sudah nonaktif"
Duplikat Idempotency-Key	200	—	Mengembalikan payment yang sudah ada (idempotent)
Rate limit terlampaui	429	RATE_LIMITED	"Terlalu banyak request. Coba lagi dalam 60 detik."
DB / MinIO tidak tersedia	503	SERVICE_UNAVAILABLE	"Layanan sedang tidak tersedia. Silakan coba beberapa saat lagi."

8.5 Event dan Messaging Design

TIPS: Untuk sistem yang menggunakan event-driven / message queue. Skip jika tidak relevan.

Event / Topic	Producer	Consumer(s)	Schema	Delivery	Retention / DLQ
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	At-least-once / Lainnya	[ISI DI SINI]

CONTOH:

Event / Topic	Producer	Consumer(s)	Schema	Delivery	Retention / DLQ
payment.submitted	Payment Service (goroutine post-commit)	Notification Service, Audit Service	{ paymentId, nomorPengajuan, pemohonId, nominal, approverId, timestamp }	At-least-once (goroutine + retry)	Buffer in-memory, retry 3x, kemudian log + alert
payment.approved	Approval Service	Notification Service, Audit Service, Accounting Service	{ paymentId, approverId, level, decision, timestamp }	At-least-once	Sama seperti di atas
user.role_changed	Admin Service	Auth Service (invalidasi session), Audit Service	{ userId, oldRole, newRole, changedBy, timestamp }	At-least-once	Sama seperti di atas

8.6 File, Batch, dan Data Exchange Interfaces

Interface	Schedule / Trigger	Transport	Format	Validasi	Rekonsiliasi
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Interface	Schedule / Trigger	Transport	Format	Validasi	Rekonsiliasi
Ekspor Harian DWH	Setiap malam 02:00 WIB (cron)	SFTP push ke server DWH	CSV (UTF-8, comma-delimited, baris header)	Cocokkan jumlah baris, file checksum, validasi schema	Tim DWH konfirmasi penerimaan + jumlah baris sebelum 06:00 WIB
Impor Master Vendor	On-demand (Admin memicu via UI)	Upload file (CSV) → API endpoint	CSV (NamaVendor, NPWP, Alamat, Rekening, Bank)	Validasi format, cek duplikat NPWP, cek field wajib	Laporan impor: jumlah berhasil, dilewati, baris error
Laporan Bulanan PDF	Tanggal 1 setiap bulan 05:00 WIB (cron)	Di-generate internal → MinIO → lampiran email	PDF (A4, landscape untuk tabel)	Validasi template, cek kelengkapan data	Finance konfirmasi penerimaan dan review

8.7 External Integration Resilience

Dependency	Timeout	Retry	Circuit Breaker	Fallback	Rekonsiliasi
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Dependency	Timeout	Retry	Circuit Breaker	Fallback	Rekonsiliasi
UIM Next-G (SSO)	5 dtk koneksi, 10 dtk baca	2x dengan 1 dtk backoff	Buka setelah 5 kegagalan dalam 30 dtk, half-open setelah 60 dtk	Kembalikan 503 "Layanan autentikasi tidak tersedia"	Health check setiap 30 dtk
HCS (Data Karyawan)	5 dtk koneksi, 10 dtk baca	3x dengan exponential backoff	Buka setelah 3 kegagalan	Sajikan dari cache lokal (basi 1 jam)	Sinkronisasi penuh setiap malam
Email SMTP	3 dtk koneksi, 10 dtk baca	3x dengan interval 5 dtk	Tanpa circuit breaker	Antrikan ke tabel retry, proses setiap 5 menit	Laporan harian email gagal kirim
MinIO (Penyimpanan File)	5 dtk koneksi, 30 dtk baca	2x	Buka setelah 5 kegagalan	Kembalikan error, jangan blokir transaksi	Health check endpoint
DWH (Data Warehouse)	10 dtk koneksi, 60 dtk baca	Tanpa retry (batch job)	N/A	Lewati batch, retry jadwal berikutnya	Rekonsiliasi jumlah baris

---

9. Detailed Component & Behavioral Design

DEV -- Bagian ini mendetailkan desain internal setiap komponen/module dan behavioral design untuk flow kritis.

9.1 Critical Flow Inventory

Flow ID	Flow Name	Trigger	Components	Diagram Type	Requirement IDs
FLOW-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Sequence / Activity / State	[ISI DI SINI]

CONTOH:

Flow ID	Flow Name	Trigger	Components	Diagram Type	Requirement IDs
FLOW-001	Submit Pengajuan Pembayaran	User clicks Submit	FE → Auth middleware → Payment Handler → Payment Service → Repository → DB → Audit (async) → Notification (async)	Sequence	FR-PAY-001, FR-PAY-002
FLOW-002	Multi-Level Approval	Approver clicks Approve/Reject	FE → Auth → Approval Handler → Approval Service → State Machine → Notification → Audit	Sequence + State	FR-PAY-003, BR-002, BR-003
FLOW-003	User Login (SSO)	User visits /login	FE → Backend → UIM Next-G (OAuth) → JWT issue → Redis session	Sequence	FR-AUTH-001
FLOW-004	Dashboard Data Load	User opens /dashboard	FE → Backend → Redis cache check → DB aggregation query (if miss) → Response	Sequence	FR-RPT-001, NFR-PERF-001

9.2 Module: [ISI DI SINI -- Nama Module]

9.2.1 Tanggung Jawab

Aspek	Deskripsi
Purpose	[ISI DI SINI -- Mengapa komponen ini ada]
Responsibilities	[ISI DI SINI -- Tanggung jawab yang dimiliki]
Non-responsibilities	[ISI DI SINI -- Batasan eksplisit, apa yang TIDAK dilakukan]
Deployment Unit	[ISI DI SINI -- Process / Container / Function / Library]
Data Owned	[ISI DI SINI -- Entity / tabel / topic / file yang dimiliki]

CONTOH:

Aspek	Deskripsi
Purpose	Mengelola seluruh lifecycle pengajuan pembayaran — dari draft hingga pencairan
Responsibilities	Submit pengajuan, validasi budget, approval workflow (state machine), pencairan, tracking status, history
Non-responsibilities	TIDAK mengelola master vendor (Admin Module). TIDAK mengirim notifikasi langsung (delegasi ke Notification Service). TIDAK menulis audit log langsung (delegasi ke Audit Service).
Deployment Unit	Module dalam monolith binary — services/payment/
Data Owned	Tables: Payments, PaymentApprovals, PaymentDocuments. Files: uploaded invoices di MinIO (/payments/{id}/)

9.2.2 Internal Structure

[module-name]/
+-- handler.go          <- HTTP handler (presentation layer)
+-- service.go          <- Business logic
+-- repository.go       <- Data access
+-- models.go           <- Request/Response DTOs
+-- entities.go         <- Domain entities
+-- constants.go        <- Module-specific constants

9.2.3 Key Functions

Function	Layer	Input	Output	Deskripsi
[ISI DI SINI]	Handler	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
[ISI DI SINI]	Service	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
[ISI DI SINI]	Repository	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Function	Layer	Input	Output	Deskripsi
CreatePayment	Handler	*fiber.Ctx (POST body: CreatePaymentDTO)	201 + PaymentResponse / 4xx error	Parsing request, validasi DTO, panggil service, kembalikan response
CreatePayment	Service	CreatePaymentDTO, userId	Payment, error	Validasi anggaran, generate nomor pengajuan, mulai TX, simpan, trigger async (audit + notifikasi)
ValidateBudget	Service	unitKerjaId, nominal	error (nil jika OK)	Cek sisa anggaran unit kerja. Kembalikan error jika nominal > sisa anggaran.
ProcessApproval	Service	paymentId, approverId, decision, comment	Payment (updated), error	Transisi state machine (Submitted→Approved/Rejected), validasi SoD, trigger notifikasi
InsertPayment	Repository	Payment entity	error	INSERT INTO Payments (...) dalam transaksi
GetPaymentsByUnit	Repository	unitKerjaId, filters, pagination	[]Payment, totalCount, error	SELECT terparameterisasi dengan filter + pagination

9.2.4 Processing Logic

TIPS: Gunakan pseudocode hanya untuk logika yang tidak obvious. Jangan duplikasi source code standar.

[ISI DI SINI -- Pseudocode untuk business logic yang kompleks]

Contoh:
function processCommand(command):
    validate(command)
    ensureIdempotency(command.idempotencyKey)
    begin transaction
        load aggregate
        apply business rules
        persist changes
        write outbox event
    commit transaction
    return result

9.2.5 State Transitions (jika ada)

[State 1] --[trigger]--> [State 2] --[trigger]--> [State 3]
                                    --[trigger]--> [State 4]

Current State	Event / Condition	Next State	Action	Invalid Transition Handling
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Error / Ignore / Escalate

CONTOH (Payment State Machine):

Draft --[Submit]--> Submitted --[Approve L1]--> Approved_L1 --[Approve L2]--> Approved --[Disburse]--> Paid
                    |                          |                               |
                    +--[Reject]---> Rejected   +--[Reject]---> Rejected       +--[Cancel]--> Cancelled
                    |
                    +--[Cancel]---> Cancelled

Current State	Event / Condition	Next State	Action	Invalid Transition Handling
Draft	User klik Submit + validasi lolos	Submitted	Notifikasi Approver L1, audit log	Error 400 jika validasi gagal
Submitted	Approver L1 menyetujui	Approved_L1	Notifikasi Approver L2 (jika threshold), audit log	Error 403 jika bukan approver berwenang
Submitted	Approver menolak	Rejected	Notifikasi pemohon, audit log	Abaikan jika sudah ditolak
Approved_L1	Approver L2 menyetujui	Approved	Notifikasi Finance untuk pencairan, audit log	Error 403 jika bukan approver L2
Approved	Finance mencairkan	Paid	Catat bukti pembayaran, audit log	Error jika sudah dibayar
Any (kecuali Paid)	User membatalkan	Cancelled	Audit log	Error jika status = Paid (tidak dapat dibatalkan)

9.2.6 Error Handling dan Recovery

Failure Mode	Detection	Caller Response	Retry / Recovery	Alert
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Failure Mode	Detection	Caller Response	Retry / Recovery	Alert
Timeout koneksi DB	SQL timeout error di repository	503 "Layanan sementara tidak tersedia"	Auto-retry 1x (refresh connection pool). Jika masih gagal, kembalikan 503.	Alert jika > 3 kegagalan dalam 5 menit
Upload MinIO gagal	S3 client error	500 "Upload file gagal" — transaksi di-rollback (payment tidak tersimpan)	Retry 2x dengan 1 dtk backoff. Jika masih gagal, kembalikan error.	Alert jika > 5 kegagalan dalam 10 menit
Validasi token UIM gagal	JWT verification error	401 "Session berakhir"	Tanpa retry — redirect ke login	Alert jika > 10 kegagalan auth per user dalam 30 menit (brute force)
Cek anggaran — tidak cukup	Business rule: nominal > sisa anggaran	400 "Nominal melebihi sisa anggaran"	Tanpa retry — user harus mengurangi nominal	Tanpa alert (alur bisnis normal)
Pengiriman email notifikasi gagal	SMTP error	Payment tetap tersimpan (side effect async). Email diantrikan untuk retry.	Retry 3x dengan interval 5 dtk. Jika masih gagal, catat ke tabel failed_notifications.	Alert jika > 10 email gagal kirim

9.2.7 Observability dan Acceptance Criteria

Signal / Criterion	Name / Statement	Required Context	Purpose / Verification	Retention
Log	[ISI DI SINI]	Correlation ID, Actor, Result, Latency	Troubleshooting / Audit	[ISI DI SINI]
Metric	[ISI DI SINI]	Labels	SLO / Capacity	Dashboard
Trace	[ISI DI SINI]	Attributes	Dependency analysis	Platform
Acceptance	[ISI DI SINI]	Precondition	Test / Analysis / Review	Test ID

CONTOH:

Signal / Criterion	Name / Statement	Required Context	Purpose / Verification	Retention
Log	payment.created	correlation_id, user_id, payment_id, nominal, vendor_id, latency_ms	Troubleshooting + Audit trail	3 tahun
Log	payment.approval.decided	correlation_id, approver_id, payment_id, decision (approve/reject), level	Audit trail	5 tahun
Metric	payment_submissions_total (counter)	Labels: status (success/error), unit_kerja	SLO tracking, capacity planning	Dashboard (Grafana)
Metric	payment_submission_duration_seconds (histogram)	Labels: quantile (p50/p95/p99)	Latency SLO verification	Dashboard
Trace	CreatePayment span	service=payment, http.method=POST, http.status, db.duration	Dependency analysis, bottleneck identification	7 hari
Acceptance	Operator dapat submit pengajuan lengkap dalam < 5 menit	User logged in, vendor exists, budget available	Functional test	TC-PAY-001

9.2.8 Dependencies

Depends On	Tipe	Untuk Apa
[Module/Service lain]	Internal	[ISI DI SINI]
[External service]	External	[ISI DI SINI]

CONTOH:

Depends On	Tipe	Untuk Apa
Auth Service (middleware)	Internal	JWT validation, user context extraction
Admin Module (service call)	Internal	Lookup vendor data, GL codes
Notification Service	Internal	Send approval notification email (async)
Audit Service	Internal	Write audit trail entry (async)
File Service	Internal	Upload/download dokumen pendukung
UIM Next-G	External	Token validation (via Auth middleware)
MinIO	External	Store uploaded files (via File Service)

[Ulangi Bagian 9.X untuk setiap module.]

9.3 Business Rules dan Decision Tables

Rule ID	Condition	Decision / Action	Prioritas	Error / Message
BR-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Rule ID	Condition	Decision / Action	Prioritas	Error / Message
BR-001	Nominal pengajuan > sisa anggaran unit kerja	Tolak submission	H	"Nominal melebihi sisa anggaran (sisa: Rp X)"
BR-002	Nominal > Rp 100 juta	Require approval level 3 (Director)	H	— (routing rule)
BR-003	Submitter == Approver (same user)	Tolak — segregation of duty	H	"Pemohon tidak boleh menjadi approver"
BR-004	Approval pending > 2 hari kerja	Auto-escalate ke approver level berikutnya + alert	M	Notifikasi "Approval SLA terlewati"
BR-005	Dokumen pendukung tidak di-upload	Tolak submission	H	"Dokumen pendukung wajib di-upload"

9.4 Algorithm Specification

TIPS: Hanya untuk algoritma yang non-trivial. Tidak perlu untuk CRUD standar.

Atribut	Spesifikasi
Algoritma / Function	[ISI DI SINI]
Purpose	[ISI DI SINI]
Inputs	[ISI DI SINI -- + preconditions]
Outputs	[ISI DI SINI -- + postconditions]
Complexity target	[ISI DI SINI -- Time / Space]
Edge cases	[ISI DI SINI]
Fallback	[ISI DI SINI]

CONTOH:

Atribut	Spesifikasi
Algoritma / Function	DetermineApprovalRoute(payment) — menentukan chain approval berdasarkan nominal dan unit kerja
Purpose	Routing pengajuan ke approver yang tepat berdasarkan threshold nominal dan hierarki organisasi
Inputs	payment.Nominal, payment.UnitKerjaId, payment.KategoriId. Precondition: payment status = Submitted.
Outputs	[]ApprovalStep { Level, ApproverId, Threshold }. Postcondition: minimal 1 step, maksimal 3 steps.
Complexity target	O(1) — lookup table, bukan iterasi. Max 3 levels hardcoded.
Edge cases	(1) Nominal = 0 → reject sebelum routing. (2) Unit kerja tidak punya approver → escalate ke Admin. (3) Approver yang sama di L1 dan L2 → skip L2, langsung ke L3. (4) Approver sedang cuti → fallback ke backup approver.
Fallback	Jika routing gagal (approver tidak ditemukan untuk level manapun): reject submission dengan error "Tidak dapat menentukan approver. Hubungi administrator."

9.5 Scheduled dan Background Jobs

Job	Schedule / Trigger	Input	Output	Idempotency	Failure Handling	Owner
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Job	Schedule / Trigger	Input	Output	Idempotency	Failure Handling	Owner
DWH Data Sync	Nightly 02:00 WIB	Transaksi hari ini dari DB	CSV push ke DWH SFTP	Dedup by transaction_id + date	Retry 3x, alert jika gagal, skip hari ini	DevOps
Approval SLA Check	Every 30 min (cron)	Pending approvals > SLA threshold	Escalation notification	Idempotent — skip jika sudah escalated	Log error, continue to next	Backend Team
Backup Verification	Daily 04:00 WIB	Latest backup file	Restore test report (pass/fail)	N/A — always runs	Alert Security Lead jika restore fail	DevOps
Inactive Session Cleanup	Every 1 hour	Sessions older than 8 hours	Deleted sessions	Safe — deletes by timestamp	Log count, continue	Backend Team

9.6 Sequence Diagrams

DEV QA -- Sequence diagram menunjukkan URUTAN interaksi antar-komponen untuk flow tertentu. Prioritaskan: critical journeys, multi-system flows, complex rules, security decisions, transactions, async processing, recovery paths.

Flow: [ISI DI SINI -- Nama Flow]

[ISI DI SINI -- Sequence diagram dalam format teks/Mermaid, termasuk success, alternative, dan failure paths]

Contoh:
Browser          Frontend         Backend          Database         External
   |                |                |                |                |
   |-- Click ------>|                |                |                |
   |                |-- POST /api -->|                |                |
   |                |                |-- BEGIN TX --->|                |
   |                |                |-- INSERT ----->|                |
   |                |                |<-- OK ---------|                |
   |                |                |-- COMMIT ----->|                |
   |                |                |                |                |
   |                |                |-- Send Email ---------------------->|
   |                |                |                |                |
   |                |<-- 201 --------|                |                |
   |<-- Toast ------|                |                |                |

[Tambahkan sequence diagram untuk setiap flow kritis.]

---

10. Frontend Architecture

DEV -- Bagian ini khusus untuk desain frontend. Skip jika proyek tidak memiliki frontend.

10.1 Application Structure

src/
+-- components/
|   +-- common/          <- Shared/reusable components
|   +-- [module]/        <- Module-specific components
+-- pages/               <- Route-level components
+-- hooks/               <- Custom hooks
+-- services/            <- API call functions
+-- store/               <- State management
+-- types/               <- TypeScript definitions
+-- utils/               <- Pure utility functions
+-- constants/           <- App constants

10.2 Component Hierarchy

TIPS: Dokumentasikan component tree untuk halaman/flow yang kompleks.

Contoh:
PageComponent
+-- HeaderSection
+-- FilterBar
|   +-- SearchInput
|   +-- DateRangePicker
|   +-- StatusFilter
+-- DataTable
|   +-- TableHeader
|   +-- TableRow (per item)
|   |   +-- ActionButtons
|   +-- Pagination
+-- CreateModal
    +-- FormFields
    +-- SubmitButton

10.3 State Management Design

State	Scope	Storage	Update Trigger
User session	Global	[ISI DI SINI]	Login/Logout
Server data (lists)	Per-page	[ISI DI SINI -- contoh: React Query]	API fetch, mutation invalidation
Form state	Local	[ISI DI SINI -- contoh: React Hook Form]	User input
UI state (modal, tab)	Local	useState	User interaction

CONTOH:

State	Scope	Storage	Update Trigger
Session user (auth, profil)	Global	Zustand store + httpOnly cookie	Login/Logout, refresh token
Daftar payment	Per-halaman	React Query (useQuery('payments'))	Saat halaman dimuat, invalidasi setelah mutasi (create/update/delete payment)
Form payment	Local	React Hook Form (useForm)	Input user, reset saat submit/cancel
Buka/tutup modal	Local	useState(false)	Klik tombol, tekan Escape
Tab aktif	Local	useState('details')	Klik tab, sinkronisasi URL param

10.4 Routing Design

Route	Component	Auth Required	Permission	States / Errors
/	Dashboard	Yes	--	[ISI DI SINI]
/[module]	[Module]List	Yes	read	Loading / Empty / Error / Success
/[module]/:id	[Module]Detail	Yes	read	[ISI DI SINI]
/[module]/create	[Module]Create	Yes	create	[ISI DI SINI]
/login	Login	No	--	[ISI DI SINI]

CONTOH:

Route	Component	Auth Required	Permission	States / Errors
/	Dashboard	Yes	—	Loading (skeleton), Error (retry button), Success (widgets)
/payments	PaymentList	Yes	payment:read	Loading, Empty ("Belum ada pengajuan"), Error, Success (table)
/payments/:id	PaymentDetail	Yes	payment:read	Loading, 404 ("Pengajuan tidak ditemukan"), Success (detail + approval history)
/payments/create	PaymentCreate	Yes	payment:create	Form (validation errors inline), Submitting (disabled button), Success (redirect to list)
/admin/users	UserManagement	Yes	admin:user	Loading, Empty, Error, Success. 403 if no admin permission.
/login	Login	No	—	Form, Submitting, Error ("Username atau password salah"), MFA prompt

10.5 UI Design References

TIPS: Referensikan artefak UI/UX yang di-approve. Dokumentasikan behavior yang mempengaruhi desain teknis: validasi, state, navigasi, error, permission, accessibility, dan telemetry.

Screen / Route	Purpose	Roles	Key Components	API Dependencies	States / Errors
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Loading / Empty / Error / Success

CONTOH:

Screen / Route	Purpose	Roles	Key Components	API Dependencies	States / Errors
/payments	Daftar pengajuan pembayaran dengan filter dan pagination	Operator, Approver, Admin	FilterBar, DataTable, Pagination, CreateButton	GET /api/v1/payments (list), DELETE /api/v1/payments/:id	Loading (skeleton table), Empty ("Belum ada pengajuan"), Error (retry), Success
/payments/create	Form pengajuan pembayaran baru	Operator	PaymentForm (wizard 4 step), VendorSelector, FileUpload, SubmitButton	POST /api/v1/payments, GET /api/v1/vendors, GET /api/v1/gl-codes	Form (inline validation), Submitting (disabled), Budget exceeded (error), Success (redirect)
/dashboard	Dashboard KPI keuangan	Management, Admin	WidgetGrid (6 widgets), DateRangePicker, UnitKerjaFilter	GET /api/v1/dashboard/summary, GET /api/v1/dashboard/charts	Loading (skeleton widgets), Error (per-widget retry), Success

---

11. Security & Privacy Design

DEV QA SEC -- Security by design, bukan by afterthought. Desain kontrol keamanan yang threat-informed dan testable.

11.1 Security Context dan Trust Boundaries

[ISI DI SINI -- Security data flow diagram dengan trust boundaries]

CONTOH:

Trust Boundaries:

╔═══════════════════════════════════════════════════════════╗
║  UNTRUSTED (Internet / User Device)                      ║
║  [Browser] ── user input, auth cookie ──┐               ║
╠═════════════════════════════════════════╪═══════════════╣
║  DMZ                                    │               ║
║  [Nginx] ◄── HTTPS/TLS 1.3 ────────────┘               ║
║  WAF rules, rate limiting, SSL termination               ║
╠═════════════════════════════════════════════════════════╣
║  TRUSTED (Internal Network / K8s cluster)                ║
║  [Backend API] ── JWT validation, Casbin RBAC            ║
║       │── [SQL Server] (TDE encrypted, PII fields)       ║
║       │── [Redis] (sessions, cache — requirepass)        ║
║       │── [MinIO] (files — SSE-S3 encrypted)             ║
║       └── [Audit DB] (append-only, hash chain)           ║
╠═════════════════════════════════════════════════════════╣
║  EXTERNAL (Third-party systems)                          ║
║  [UIM Next-G] ◄── HTTPS ── Backend (OAuth token flow)   ║
║  [HCS] ◄── HTTPS ── Backend (employee lookup)           ║
║  [SMTP] ◄── STARTTLS ── Backend (email notification)    ║
╚═════════════════════════════════════════════════════════╝

Aset sensitif yang melintas boundary:
- Kredensial user: UNTRUSTED → DMZ (HTTPS) → TRUSTED (JWT cookie, tidak pernah di URL/log)
- PII (NIP, NPWP): hanya di TRUSTED (terenkripsi at rest, di-masking di log)
- Data audit: TRUSTED → TRUSTED (DB append-only, tidak pernah keluar ke UNTRUSTED)
- File: UNTRUSTED → DMZ → TRUSTED (scan virus sebelum disimpan, signed URL untuk download)

11.2 Threat Model

TIPS: Identifikasi aset, penyerang, abuse case, dan threat menggunakan metode yang disetujui (STRIDE, dll).

Threat ID	Asset / Flow	Skenario Threat	Impact (C/I/A)	Control(s)	Residual Risk
THR-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Threat ID	Asset / Flow	Skenario Threat	Impact (C/I/A)	Control(s)	Residual Risk
THR-001	Alur login	Serangan brute force password	C: kredensial terkompromi	Rate limiting (5 percobaan/30 menit), account lockout, MFA	Rendah — dimitigasi oleh lockout + MFA
THR-002	API endpoint	Akses tidak sah melalui pencurian token	C/I: kebocoran data, manipulasi data	httpOnly cookie, JWT berumur pendek (15 menit), rotasi refresh	Sedang — jendela session hijack masih ada
THR-003	Upload file	Upload file berbahaya (webshell, virus)	I/A: server terkompromi	Whitelist tipe file, scan AV, penyimpanan terisolasi, tanpa permission eksekusi	Rendah
THR-004	Audit log	Manipulasi catatan audit	I: kegagalan kepatuhan	Penyimpanan append-only, hash chain, kredensial DB terpisah, tanpa permission DELETE	Rendah
THR-005	Database	SQL injection	C/I: pencurian data, manipulasi data	Hanya parameterized query (tanpa string concatenation), scan SAST	Rendah

11.3 Authentication Design

Identity Type	Authentication Method	Credential / Token	Lifetime	Revocation	MFA
End user	[ISI DI SINI -- OIDC / SAML / Local]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Required / Conditional
Service	[ISI DI SINI -- mTLS / Client Credentials]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	N/A

CONTOH:

Identity Type	Authentication Method	Credential / Token	Lifetime	Revocation	MFA
End user	OAuth 2.0 via UIM Next-G	JWT access token (httpOnly cookie) + refresh token	Access: 15 menit, Refresh: 7 hari	Endpoint logout menghapus cookie + session Redis. Rotasi refresh setiap penggunaan.	Wajib untuk role Approver + Admin
Service-to-service	API key di header (X-API-Key)	API key statis per service	Tanpa expiry (dirotasi manual)	Pencabutan key via update konfigurasi + restart	N/A
Batch job	Service account dengan permission terbatas	JWT diterbitkan saat job dimulai	Selama durasi eksekusi job	Auto-expire setelah job selesai	N/A

11.4 Authorization Design

Role / Policy	Permitted Actions	Data Scope	Enforcement Point	Approval / Provisioning
Admin	[ISI DI SINI]	[ISI DI SINI]	UI / API / DB	[ISI DI SINI]
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

Permission Matrix:

Role	Module A	Module B	Module C
Admin	CRUD	CRUD	CRUD
Manager	CRU	R	CRU
User	R	R	CR

CONTOH:

Role / Policy	Permitted Actions	Data Scope	Enforcement Point	Approval / Provisioning
System Admin	CRUD semua modul, manajemen user, penugasan role, konfigurasi	Global (semua data)	API middleware (Casbin) + UI route guard	Persetujuan IT Manager, review Security Lead
Approver	Lihat + Setujui/Tolak payment di unit sendiri	Jurisdiksi: unit kerja sendiri (filter KodeUnitKerja)	API (Casbin policy) + tombol disabled di UI	Penunjukan VP/Kepala Divisi
Operator	Buat + Edit payment sendiri, Lihat payment sendiri + unit	Data sendiri (CreatedBy) + data unit (KodeUnitKerja)	API (Casbin + cek kepemilikan di service)	Penunjukan manajer unit
Auditor	Lihat semua data + audit log (read-only)	Global read-only	API (Casbin read-only policy)	Penunjukan komite audit

Permission Matrix:

Role	Payment	Admin / Master Data	Reporting	Audit Log	User Management
System Admin	CRUD	CRUD	CRUD	R	CRUD
Approver	R + Approve	R	R (own unit)	—	—
Operator	CR (own) + R (unit)	R	R (own unit)	—	—
Auditor	R (all)	R (all)	R (all)	R (all)	—

11.5 Data Protection dan Cryptography

Data State	Protection	Algorithm / Protocol	Key Ownership	Rotation	Exception
In transit	[ISI DI SINI -- TLS / mTLS]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
At rest	[ISI DI SINI -- Encryption]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Application fields	[ISI DI SINI -- Tokenization / Field Encryption]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

Data Protection per Kategori:

Data Kategori	Perlindungan	Implementasi
Password	Hash (irreversible)	[ISI DI SINI -- bcrypt/argon2]
PII (nama, email, NIP)	[ISI DI SINI]	[ISI DI SINI]
Token/Secret	[ISI DI SINI]	[ISI DI SINI]
File upload	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Data State	Protection	Algorithm / Protocol	Key Ownership	Rotation	Exception
In transit	Enkripsi TLS	TLS 1.3 (min 1.2)	Let's Encrypt / CA Klien	Auto-renew (LE) / Tahunan (klien)	Internal service-to-service: plain HTTP dalam K8s pod network (node yang sama)
At rest (DB)	Transparent Data Encryption	AES-256 (SQL Server TDE)	Hierarki key SQL Server	Master key dirotasi tahunan	Tabel non-sensitif: TDE mencakup semua, tanpa exception field-level
Application fields	Enkripsi field-level	AES-256-GCM via Go crypto	Dikelola aplikasi, disimpan di K8s Secret	Dirotasi semi-tahunan dengan migrasi re-encryption	Hanya diterapkan pada: NIK, NPWP, nomor rekening

Data Protection per Kategori:

Data Kategori	Perlindungan	Implementasi
Password	Hash (irreversible)	bcrypt cost 12. Tidak pernah disimpan plaintext. Tidak pernah di-log.
PII (nama, email, NIP)	Terenkripsi at rest (TDE) + di-masking di log	Masking log: ir***@gmail.com. Respons API: nilai lengkap hanya untuk role berwenang.
Token/Secret	Tidak pernah disimpan di DB — hanya di Redis dengan TTL	httpOnly cookie (JWT), session Redis dengan TTL 15 menit. Refresh token: TTL 7 hari dengan rotasi.
File upload	Terenkripsi at rest di MinIO	MinIO server-side encryption (SSE-S3). Scan virus sebelum disimpan. Download via signed URL (expiry 30 menit).

11.6 Secure Input, Output, dan File Handling

Control Area	Keputusan Desain	Enforcement Point	Verifikasi
Input validation	[ISI DI SINI -- Allowlist, type, length, range, format]	Client + Server	Test / Scan
Output encoding	[ISI DI SINI -- Context-specific encoding]	Template / Framework	Test
File upload	[ISI DI SINI -- Type, size, AV scan, storage, download headers]	Gateway / Service	Test
Injection prevention	[ISI DI SINI -- Parameterized query / safe API]	Data access	SAST / Test

CONTOH:

Control Area	Keputusan Desain	Enforcement Point	Verifikasi
Validasi input	Pendekatan allowlist: tipe terdefinisi, panjang maksimum, pola regex per field. Tolak field yang tidak dikenal.	FE: Zod schema. BE Handler: validator.Struct(dto). BE Service: business rules.	Unit test per aturan validasi + DAST scan
Output encoding	React otomatis escape output JSX (perlindungan XSS). Respons API: hanya JSON, tanpa rendering HTML.	React framework (default). BE: hanya c.JSON(), tidak pernah c.SendString() dengan data user.	SAST scan untuk output string mentah
Upload file	Whitelist: hanya PDF, JPG, PNG. Maks 10MB. Scan ClamAV sebelum disimpan. Content-Disposition: attachment saat download. Disimpan di MinIO (terisolasi, tanpa permission eksekusi).	BE Handler: cek tipe + ukuran. File Service: scan AV. Nginx: download headers.	Uji upload dengan file berbahaya (EICAR, polyglot)
Pencegahan injection	Semua query DB via parameterized statement (sqlx.NamedQuery / db.Query dengan ? params). Tanpa string concatenation. Tanpa raw SQL dari input user.	Hanya di repository layer. Item checklist code review.	SAST scan (gosec), code review manual

Mengacu pada TSG Aturan Umum Validasi Form (TSG-STD-VALIDASI).

Layer	Tujuan	Contoh
Frontend	UX (immediate feedback)	Required fields, format check, max length
Backend Handler	Request integrity	Type parsing, required check, max size
Backend Service	Business rules	Permission check, state validation, uniqueness
Database	Data integrity	NOT NULL, FK constraint, UNIQUE constraint

11.7 Secrets dan Configuration Security

Secret / Credential	Storage	Access	Rotation	Exposure Prevention
[ISI DI SINI]	[ISI DI SINI -- Vault / KMS / Secret Manager]	[ISI DI SINI]	[ISI DI SINI]	No code / log / image

CONTOH:

Secret / Credential	Storage	Access	Rotation	Exposure Prevention
DB connection string	K8s Secret (terenkripsi at rest)	Di-mount sebagai env var di pod	Dirotasi triwulanan	Tidak di source code, tidak di log, tidak di container image
JWT signing key	K8s Secret	Di-inject saat startup	Dirotasi semi-tahunan dengan overlap window	Asimetris (public key didistribusikan, private key dibatasi)
UIM Next-G API key	K8s Secret	Env var	Dikoordinasikan dengan IT klien	Tidak pernah di-log, di-masking di debug output
MinIO access key	K8s Secret	Env var	Dirotasi triwulanan	Kredensial terpisah per environment
Redis password	K8s Secret	Env var	Dirotasi triwulanan	requirepass diaktifkan, tanpa default password

11.8 Security Logging dan Audit

Audit Event	Actor	Object	Outcome	Required Context	Retention
[ISI DI SINI]	User / Service	[ISI DI SINI]	Success / Failure	IP, Correlation, Before/After	[ISI DI SINI]

CONTOH:

Audit Event	Actor	Object	Outcome	Required Context	Retention
Login	User	Session	Success / Failure	IP, user agent, MFA used, failure reason	3 tahun
Create Payment	User	Payment #{id}	Success	IP, correlation ID, nominal, vendor	5 tahun
Approve Payment	User	Payment #{id}	Success / Reject	IP, approval level, komentar, before/after status	5 tahun
Change Role	Admin	User #{id}	Success	IP, old role, new role, approved by	5 tahun
Export Report	User	Report #{type}	Success	IP, report type, date range, row count	3 tahun
Delete Record	Admin	Entity #{id}	Success	IP, entity type, full record snapshot (before)	5 tahun

11.9 Privacy dan Personal Data

Processing Activity	Personal Data	Purpose / Legal Basis	Access	Retention	Data Subject Rights
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Processing Activity	Personal Data	Purpose / Legal Basis	Access	Retention	Data Subject Rights
Employee authentication	Email, NIP	System access — legitimate interest + employment contract	Auth Service only	Active employment + 2 tahun	Access, correction
Payment processing	Nama pemohon, NIP, unit kerja	Operational necessity — internal financial process	Payment Module, Reporting, Audit	7 tahun (regulatory)	Access, correction (not deletion — regulatory hold)
Audit logging	User ID, IP, action, timestamps	Legal obligation (POJK) + legitimate interest	Audit Service, Security team	8 tahun	Access only (no modification/deletion allowed)
Vendor data management	Nama PIC vendor, email, NPWP	Contract performance	Admin Module, Payment Module	Duration of vendor relationship + 2 tahun	Access, correction, deletion (after retention)

11.10 Security Control Traceability

Control ID	Source Standard	Control Requirement	Design Section	Verification Evidence
SEC-001	[ISI DI SINI -- OWASP / Policy / NIST]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Control ID	Source Standard	Control Requirement	Design Section	Verification Evidence
SEC-001	OWASP A03:2021 (Injection)	Semua query DB harus menggunakan parameterized statement	§6.4 (Validation), §7.5 (Integrity)	Laporan SAST scan, checklist code review
SEC-002	OWASP A07:2021 (Auth Failures)	Account lockout setelah 5 percobaan gagal, MFA untuk role privileged	§11.3 (Authentication)	Functional test TC-AUTH-005
SEC-003	UU PDP Art. 16	Data pribadi terenkripsi at rest	§11.5 (Data Protection)	Verifikasi konfigurasi TDE, uji field encryption
SEC-004	POJK Manajemen Risiko TI	Audit trail immutable untuk semua transaksi keuangan	§11.8 (Security Logging)	Uji append-only storage, verifikasi hash chain
SEC-005	ISO 27001 A.9.4	Akses least privilege — RBAC diterapkan di API layer	§11.4 (Authorization)	Casbin policy test suite, penetration test

---

12. Non-Functional Requirements Design

DEV QA -- Setiap NFR HARUS mengandung angka, kondisi, scope, dan metode pengukuran. NFR tanpa angka bukan NFR.

12.1 Performance dan Latency Budget

TIPS: Untuk target end-to-end, alokasikan budget per komponen. Contoh: Untuk target 1 detik end-to-end, alokasikan 150ms client/network, 300ms API, 350ms database, 200ms contingency.

Transaksi / Operasi	Load	Target	Budget Allocation	Test Method
[ISI DI SINI]	[ISI DI SINI -- RPS / Users / Data Size]	p50/p95/p99: [ISI DI SINI]	Client: [X]ms, API: [X]ms, DB: [X]ms	[ISI DI SINI]

CONTOH:

Transaksi / Operasi	Load	Target	Budget Allocation	Test Method
Submit pengajuan	50 req/s peak	p50: 200ms, p95: 500ms, p99: 1s	Client: 50ms, API handler: 100ms, Service: 150ms, DB: 150ms, Contingency: 50ms	k6 load test
Dashboard load	100 req/s peak	p50: 500ms, p95: 2s	Client: 100ms, API: 200ms, Aggregation query: 1.2s, Contingency: 500ms	k6 + Lighthouse
Approval action	20 req/s peak	p50: 150ms, p95: 400ms	Client: 30ms, API: 70ms, Service: 100ms, DB: 150ms, Contingency: 50ms	k6 load test
Report PDF export	5 req/min	p50: 5s, p95: 15s	API: 500ms, Query: 3s, PDF render: 8s, Contingency: 3.5s	Manual + timer

12.2 Capacity dan Scalability

Resource / Dimension	Baseline	Peak	Growth	Scaling Trigger	Scaling Method
Requests	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI] % / year	[ISI DI SINI]	Horizontal / Vertical
Data	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI] % / year	[ISI DI SINI]	Partition / Archive / Scale
Frontend	[ISI DI SINI]	[ISI DI SINI]	--	--	CDN / Static hosting

CONTOH:

Resource / Dimension	Baseline	Peak	Growth	Scaling Trigger	Scaling Method
Requests (API)	50 req/s	200 req/s (akhir bulan closing)	30% / year	HPA: CPU > 70% for 2 min	Horizontal — add pods (max 6)
Data (DB)	50 GB	100 GB (2 tahun)	~25 GB / year	Storage > 80% alert	Vertical — expand disk. Archive data > 2 tahun.
Data (MinIO files)	100 GB	500 GB (2 tahun)	~200 GB / year	Storage > 70% alert	Expand MinIO storage. Compress archived files.
Frontend	Static assets ~50 MB	N/A	Minimal	N/A	Nginx serves static files. CDN jika perlu (future).

12.3 Availability, Reliability, dan Resilience

Service / Capability	Availability SLO	Failure Mode	Redundancy	Recovery	Degraded Mode
[ISI DI SINI]	[ISI DI SINI -- % / window]	[ISI DI SINI]	[ISI DI SINI]	RTO: [ISI DI SINI]	[ISI DI SINI]

CONTOH:

Service / Capability	Availability SLO	Failure Mode	Redundancy	Recovery	Degraded Mode
Backend API	99.5% (jendela 30 hari)	Pod crash, OOM	3 replika, K8s auto-restart	RTO: 30 dtk (auto-restart)	Pod tersisa menangani traffic, HPA scale up
SQL Server	99.5%	Kegagalan disk, korupsi	Primary + read replica	RTO: 4 jam (failover), RPO: 1 jam	Read replica melayani query baca, tulis diantrikan
Redis	99% (dapat lebih rendah)	Proses crash	Primary + replica	RTO: 5 menit (auto-restart, warm-up)	Cache miss → fallback ke DB, sedikit lebih lambat
Login (UIM Next-G)	Tergantung SLA eksternal	UIM down	— (eksternal)	Tunggu pemulihan	Tampilkan "Login sementara tidak tersedia", session yang ada tetap valid

12.4 Business Continuity dan Disaster Recovery

Asset / Service	RTO	RPO	DR Strategy	Test Frequency	Owner
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI -- Backup / Replica / Multi-site]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Asset / Service	RTO	RPO	DR Strategy	Test Frequency	Owner
Backend API	1 jam	0 (stateless)	K8s auto-restart + rolling deploy. Multi-replica.	Chaos test triwulanan	DevOps
SQL Server	4 jam	1 jam	Primary-replica, incremental backup setiap 1 jam, full backup harian	Uji restore bulanan, uji failover triwulanan	DBA
Redis	30 menit	Kehilangan dapat diterima (cache)	Auto-restart, data dapat direkonstruksi dari DB	Uji restart bulanan	DevOps
MinIO	4 jam	24 jam	Backup harian ke offsite storage	Uji restore triwulanan	DevOps
Sistem keseluruhan	4 jam	1 jam	Runbook terdokumentasi RB-003, contact tree, matriks otoritas keputusan	DR drill semi-tahunan	PM + DevOps

12.5 Accessibility, Usability, dan Localization

Concern	Target / Standard	Keputusan Desain	Verifikasi
Accessibility	[ISI DI SINI -- WCAG level / org standard]	[ISI DI SINI]	Automated + Manual
Localization	[ISI DI SINI -- Languages / Locales]	[ISI DI SINI]	Test
Usability	[ISI DI SINI -- Target / Heuristics]	[ISI DI SINI]	Test

CONTOH:

Concern	Target / Standard	Keputusan Desain	Verifikasi
Accessibility	WCAG 2.1 Level AA	ARIA labels, keyboard navigation, contrast >= 4.5:1, semantic HTML	axe-core automated scan + manual screen reader test
Localization	Bahasa Indonesia (primary), English (reports/dashboard)	i18n via react-intl, locale files per language, fallback to ID	QA checklist per language
Usability	80% pengguna baru dapat submit pengajuan tanpa pelatihan	Form berbasis wizard, validasi inline, tooltip bantuan kontekstual, layout konsisten	Observasi UAT, survei SUS (System Usability Scale) pasca-UAT

12.6 Maintainability dan Supportability

Kualitas	Mekanisme Desain	Metric / Threshold	Evidence
Maintainability	[ISI DI SINI -- Modularity, code quality, test coverage]	[ISI DI SINI]	Pipeline / Review
Supportability	[ISI DI SINI -- Diagnostics, runbooks, feature flags]	[ISI DI SINI]	ORR
Portability	[ISI DI SINI -- Container / standard runtime / abstraction]	[ISI DI SINI]	Deployment test

CONTOH:

Kualitas	Mekanisme Desain	Metric / Threshold	Evidence
Maintainability	Modular monolith (batasan modul jelas), Clean Architecture layers, penamaan konsisten	Cyclomatic complexity < 15 per fungsi, test coverage >= 70%	Laporan golangci-lint, laporan coverage di CI
Supportability	Structured logging (JSON), health endpoint (/health/live, /health/ready), feature flag untuk rollout bertahap	MTTR < 4 jam untuk SEV1, cakupan runbook 100% untuk flow kritis	Runbook index (§14.7), incident post-mortem
Portability	Docker container, tanpa dependensi host-specific, konfigurasi via env var	Deploy ke K8s cluster manapun dengan manifest yang sama	Diuji di dev + staging + production (3 environment berbeda)

---

13. Infrastructure & Deployment Design

DEV -- Bagian ini mendeskripsikan bagaimana sistem di-deploy dan dioperasikan.

13.1 Environment Strategy

Environment	Purpose	Data Class	Topology	Deployment Trigger	Access
Development	Pengembangan harian	Synthetic / Masked	[ISI DI SINI]	On commit / Manual	Dev team
Test / SIT	Integration testing	Synthetic / Masked	[ISI DI SINI]	Pipeline	QA team
UAT	User acceptance testing	Masked / Approved	[ISI DI SINI]	Release candidate	Business + QA
Production	Live system	Production	[ISI DI SINI -- HA topology]	Approval gate	Least privilege

13.2 Deployment Topology

[ISI DI SINI -- Deployment diagram dengan network zones, nodes, ports, dan data stores.]

Contoh:
+-----------------------------------------------------+
|                   Internet                           |
+------------------------+----------------------------+
                         v
                +-----------------+
                |  Reverse Proxy  | (Nginx)
                |  + SSL Term     |
                +--------+--------+
                         |
            +------------+------------+
            v            v            v
     +------------+ +--------+ +----------+
     |  Frontend  | |Backend | |   AI     |
     |  (Static)  | |  API   | | Service  |
     +------------+ +---+----+ +----+-----+
                        |           |
                        v           v
                +-----------+ +----------+
                |  Database | | pgvector |
                |  (MSSQL)  | |          |
                +-----------+ +----------+

13.3 Network dan Connectivity Matrix

Source	Destination	Protocol / Port	Direction	Purpose	Security Control
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Inbound / Outbound	[ISI DI SINI]	Firewall / mTLS / Private Link

CONTOH:

Source	Destination	Protocol / Port	Direction	Purpose	Security Control
Browser (User)	Nginx (Reverse Proxy)	HTTPS / 443	Inbound	Web application access	TLS 1.3, WAF rules
Nginx	Backend API	HTTP / 3000	Internal	Route API requests	Private network, no external exposure
Nginx	Frontend Static	HTTP / 8080	Internal	Serve SPA assets	Private network
Backend API	SQL Server	TCP / 1433	Internal	Database queries	Private network, DB firewall, credential rotation
Backend API	Redis	TCP / 6379	Internal	Cache + session	Private network, requirepass
Backend API	MinIO	HTTP / 9000	Internal	File storage	Private network, access key + secret key
Backend API	UIM Next-G	HTTPS / 443	Outbound	SSO token validation	TLS 1.3, API key
Backend API	SMTP Server	TCP / 587	Outbound	Email notification	STARTTLS, SMTP auth

13.4 Infrastructure Resource Specification

Resource	Environment	Sizing (CPU/Memory)	HA / Replicas	Storage	Autoscaling
[ISI DI SINI]	Production	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Resource	Environment	Sizing (CPU/Memory)	HA / Replicas	Storage	Autoscaling
Backend API	Production	4 vCPU, 8GB RAM	3 replicas (min 2)	—	HPA: CPU > 70% → scale up, max 6
Frontend (Nginx)	Production	1 vCPU, 1GB RAM	2 replicas	10GB (static assets)	—
SQL Server	Production	8 vCPU, 32GB RAM	Primary + 1 read replica	500GB SSD (RAID 10)	Vertical only
Redis	Production	2 vCPU, 4GB RAM	Primary + 1 replica	10GB	—
MinIO	Production	2 vCPU, 4GB RAM	1 instance	1TB	Monitor, manual expand
ELK Stack	Production	4 vCPU, 16GB RAM (ES x3)	3-node cluster	500GB	—
Prometheus + Grafana	Production	2 vCPU, 4GB RAM	1 instance	100GB	—

13.5 Configuration Management

Configuration Item	Source of Truth	Scope	Secret	Change Method	Validation
[ISI DI SINI]	[ISI DI SINI -- Repo / Config Service]	Env / Tenant / Global	Y/N	PR / Pipeline	Schema / Test

CONTOH:

Configuration Item	Source of Truth	Scope	Secret	Change Method	Validation
DB connection string	K8s Secret	Per-env	Y	PR DevOps + pipeline deploy	Uji koneksi saat startup
Feature flag	File konfigurasi di repo (config/features.json)	Per-env	N	PR + merge ke branch	Validasi schema di CI
CORS allowed origins	Konfigurasi Nginx	Per-env	N	PR DevOps	Smoke test pasca-deploy
Threshold rate limit	File konfigurasi (config/rate-limit.json)	Global	N	PR + merge	Unit test
Casbin policy	File CSV di repo (config/casbin_policy.csv)	Global	N	PR + review oleh Security Lead	Policy test suite
Log level	Env var (LOG_LEVEL)	Per-env	N	Update K8s ConfigMap	Perubahan runtime, tanpa restart

13.6 Deployment dan Release Strategy

Stage	Entry Criteria	Activity	Exit Criteria	Rollback Trigger
Build	[ISI DI SINI]	Compile, test, package, sign	Artifact + evidence	Failure
Deploy	[ISI DI SINI]	[ISI DI SINI -- Blue/Green / Canary / Rolling]	Healthy	SLO / Error rate
Verify	Deployed	Smoke / Synthetic / Observe	Accepted	Threshold breach

CONTOH:

Stage	Entry Criteria	Activity	Exit Criteria	Rollback Trigger
Build	Kode sudah merge ke branch staging, CI pipeline hijau	go build, npm run build, build Docker image + tag (git SHA), push ke registry	Image di registry, artefak build ditandatangani	Build gagal → perbaiki kode
Deploy ke Staging	Build berhasil, environment staging tersedia	Rolling update via kubectl apply — 1 pod per waktu, cek readiness probe	Semua pod sehat, /health/ready mengembalikan 200	Pod gagal readiness selama > 2 menit
Verifikasi Staging	Sudah di-deploy ke staging	Suite smoke test otomatis (10 flow kritis), pengujian manual QA (3 hari)	Smoke test 100% pass, sign-off QA	Smoke test gagal → rollback staging
Deploy ke Production	Staging terverifikasi, persetujuan PM + Tech Lead	Rolling update — sama dengan staging. Pantau error rate + latency selama 30 menit pasca-deploy	Error rate < 0.5%, latency p95 < 500ms selama 30 menit	Error rate > 2% atau latency p95 > 1 dtk selama 5 menit → rollback otomatis

13.7 Database Deployment dan Schema Change

Change Type	Method	Compatibility Rule	Rollback / Roll-forward	Validation
Additive schema	[ISI DI SINI -- Migration tool]	Backward compatible	[ISI DI SINI]	Test
Breaking change	[ISI DI SINI -- Expand / Migrate / Contract]	No single-step break	[ISI DI SINI]	Test

CONTOH:

Change Type	Method	Compatibility Rule	Rollback / Roll-forward	Validation
Tambah kolom (nullable)	File SQL migration: YYYYMMDD_add_column.up.sql + .down.sql	Backward compatible — kode lama mengabaikan kolom baru	Down migration: ALTER TABLE DROP COLUMN	Jalankan up+down+up di staging sebelum production
Tambah index	File SQL migration	Backward compatible — transparan terhadap query	Down migration: DROP INDEX	Uji performa query sebelum/sesudah di staging
Rename kolom	Expand-Migrate-Contract: (1) Tambah kolom baru, (2) Backfill + dual-write, (3) Ganti kode ke kolom baru, (4) Hapus kolom lama	Setiap langkah dapat di-deploy independen	Revert ke langkah sebelumnya	Setiap langkah diuji independen
Hapus kolom	Hanya setelah semua referensi kode dihapus (diverifikasi dengan grep + build)	Harus menjadi langkah terakhir Expand-Migrate-Contract	Tidak dapat di-rollback — pastikan tidak ada kode yang bergantung sebelum menghapus	Pencarian kode + verifikasi build

13.8 CI/CD Pipeline

[Push] -> [Build] -> [Lint + SAST] -> [Unit Test] -> [Deploy Staging] -> [Smoke Test] -> [Manual Approval] -> [Deploy Prod]

[ISI DI SINI -- Detailkan setiap stage jika perlu.]

---

14. Observability & Operational Design

DEV QA -- Membuat sistem diagnosable, recoverable, dan supportable di setiap environment.

14.1 Logging Standard

Kategori	Aturan
Format	Structured logs dalam [ISI DI SINI -- JSON / standard format]
Correlation	Setiap request dan async flow HARUS membawa correlation dan trace identifier
Sensitive data	Credentials, tokens, secrets, dan PII TIDAK BOLEH di-log
Levels	[ISI DI SINI -- DEBUG / INFO / WARN / ERROR usage rules]
Retention	[ISI DI SINI -- per log type dan environment]
Access	[ISI DI SINI -- Role-based access dan audit]

CONTOH:

Kategori	Aturan
Format	Structured JSON: {"timestamp", "level", "message", "request_id", "user_id", "module", "action", "latency_ms"}
Correlation	Setiap HTTP request mendapat X-Correlation-ID (UUID). Async job mewarisi correlation ID induk.
Sensitive data	TIDAK boleh di-log: password, token, NIK, nomor rekening. Masking: email → ir***@gmail.com
Levels	DEBUG: hanya development. INFO: lifecycle request, event bisnis. WARN: masalah yang dapat dipulihkan. ERROR: kegagalan yang tidak dapat dipulihkan.
Retention	Production: 30 hari hot (Elasticsearch), 1 tahun cold (S3/MinIO). Non-production: 7 hari.
Access	Penampil log: Dev + Ops. Audit log: Auditor + Security. Log yang mengandung PII: akses terbatas + persetujuan DPO.

14.2 Metrics dan Service Level Indicators

Metric / SLI	Type	Definition	Target / Threshold	Dashboard / Alert
Availability	SLI	[ISI DI SINI -- Successful valid requests / Valid requests]	[ISI DI SINI]	[ISI DI SINI]
Latency	SLI	[ISI DI SINI -- P95 for key transaction]	[ISI DI SINI]	[ISI DI SINI]
[ISI DI SINI]	Counter / Gauge / Histogram	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Metric / SLI	Type	Definition	Target / Threshold	Dashboard / Alert
Availability	SLI	Request berhasil (2xx+3xx) / Total request valid (excl. 4xx client error)	>= 99.5% dalam jendela 30 hari	Grafana SLO dashboard, alert < 99%
Latency (p95)	SLI	Persentil ke-95 response time untuk submit pengajuan	p95 <= 500ms	Grafana, alert > 800ms selama 5 menit
Error rate	SLI	Respons 5xx / Total respons	< 0.5%	Grafana, alert > 1% selama 5 menit
Request rate	Counter	Total HTTP request per detik	Baseline: 50 rps, alert > 200 rps (lonjakan tidak terduga)	Grafana
Penggunaan pool koneksi DB	Gauge	Koneksi aktif / Ukuran pool maks	Warning > 70%, Critical > 90%	Grafana + AlertManager
Throughput audit log	Counter	Event audit yang ditulis per menit	Baseline: 100/menit, alert jika 0 selama > 10 menit	Grafana

14.3 Distributed Tracing

Span / Operation	Required Attributes	Sampling	Sensitive Data Rule
[ISI DI SINI]	Service, Route, Result, Tenant (as allowed)	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Span / Operation	Required Attributes	Sampling	Sensitive Data Rule
HTTP Request (inbound)	service, http.method, http.route, http.status_code, latency_ms, correlation_id	100% untuk error, 10% untuk sukses (dapat disesuaikan)	JANGAN sertakan: request body, auth token, field PII
DB Query	service, db.system (mssql), db.operation (SELECT/INSERT/UPDATE), latency_ms	Sama dengan parent span	JANGAN sertakan: parameter query yang mengandung PII
External HTTP Call	service, http.url (host saja, tanpa query params), http.status_code, latency_ms	Sama dengan parent span	JANGAN sertakan: API key, auth header
Redis Operation	service, db.system (redis), db.operation (GET/SET/DEL), key_prefix, latency_ms	Sama dengan parent span	JANGAN sertakan: nilai key

14.4 Health Checks

Endpoint / Check	Purpose	Dependencies Tested	Failure Behavior	Consumer
/health/live	Process liveness	None / Minimal	Restart instance	Orchestrator
/health/ready	Traffic readiness	[ISI DI SINI -- Critical dependencies]	Remove from traffic	Load balancer

14.5 Alert dan Response Matrix

Alert	Condition	Severity	Owner	Immediate Action	Runbook
[ISI DI SINI]	[ISI DI SINI -- Condition + window]	SEV1-4	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI -- Link / ID]

CONTOH:

Alert	Condition	Severity	Owner	Immediate Action	Runbook
Error Rate API Tinggi	Error rate > 2% selama 5 menit	SEV1	Backend Team	Cek log, identifikasi endpoint yang gagal, rollback jika perlu	RB-004
Pool Koneksi DB Penuh	Penggunaan pool > 90% selama 2 menit	SEV1	DevOps	Scale koneksi DB, cek slow query, hentikan query yang berjalan lama	RB-005
Penggunaan Disk Kritis	Disk > 90% di node manapun	SEV2	DevOps	Identifikasi file/log besar, arsipkan data lama, perluas storage	RB-006
UIM Next-G Tidak Terjangkau	Health check gagal 3x berturut-turut	SEV1	DevOps + IT Klien	Cek jaringan, hubungi IT klien, pantau pemulihan	RB-007
Gap Audit Log Terdeteksi	Tidak ada event audit selama > 10 menit pada jam kerja	SEV2	Security Lead	Cek kesehatan audit service, verifikasi buffer, rekonsiliasi manual	RB-008

14.6 Backup, Restore, dan Recovery

Asset	Backup Method	Frequency	Retention	Restore Test	Encryption
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI -- Frequency + last result]	[ISI DI SINI]

CONTOH:

Asset	Backup Method	Frequency	Retention	Restore Test	Encryption
SQL Server (full)	Full backup via SQL Agent	Harian 02:00 WIB	30 hari	Uji restore bulanan ke staging — terakhir: Pass (01/07/2026)	AES-256 (TDE + backup encryption)
SQL Server (log)	Transaction log backup	Setiap 1 jam	7 hari	Termasuk dalam uji full restore	AES-256
MinIO (file)	rsync ke offsite NAS	Harian 03:00 WIB	90 hari	Uji restore file acak triwulanan — terakhir: Pass (15/06/2026)	At rest (SSE-S3)
Redis	RDB snapshot	Setiap 6 jam	3 hari	Uji load snapshot bulanan	Tidak terenkripsi (tanpa data sensitif — hanya cache)
Konfigurasi K8s	GitOps (repo infra-config)	Setiap commit	Git history (tidak terbatas)	DR drill restore dari repo — semi-tahunan	Secret terenkripsi via K8s encryption provider

14.7 Operational Runbook Index

Runbook ID	Skenario	Trigger	Owner	Location	Last Tested
RB-001	Service startup / shutdown	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
RB-002	Rollback	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
RB-003	Disaster recovery	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Runbook ID	Skenario	Trigger	Owner	Location	Last Tested
RB-001	Startup / shutdown service	Deploy manual atau restart	DevOps	/docs/runbooks/RB-001-startup.md	01/07/2026
RB-002	Rollback ke versi sebelumnya	Error rate > 2% pasca-deploy	DevOps	/docs/runbooks/RB-002-rollback.md	01/07/2026
RB-003	Disaster recovery	Kegagalan production yang tidak dapat dipulihkan	DevOps + PM	/docs/runbooks/RB-003-dr.md	15/06/2026 (DR drill)
RB-004	Error rate API tinggi	Alert: error rate > 2% selama 5 menit	Backend Team	/docs/runbooks/RB-004-api-errors.md	20/06/2026
RB-005	Pool koneksi DB penuh	Alert: pool > 90% selama 2 menit	DevOps	/docs/runbooks/RB-005-db-pool.md	25/06/2026

---

15. DevSecOps & Engineering Controls

DEV SEC -- Hubungkan desain ke kontrol engineering, verifikasi otomatis, evidence release, dan software supply chain.

15.1 Repository dan Code Organization

Repository	Contents	Owner	Branching Model	Protection Rules
[ISI DI SINI]	Source / Infra / Contract / Docs	[ISI DI SINI]	Trunk / Gitflow / Lainnya	Review / Checks / Signing

CONTOH:

Repository	Contents	Owner	Branching Model	Protection Rules
tim2-backend	Source Go backend, migration, API docs	Backend Team	Feature branch → staging → production. staging = sudah diuji QA. production = release yang disetujui.	MR wajib, minimal 1 reviewer, CI pipeline harus pass
tim2-frontend	Source React SPA, component library	Frontend Team	Sama dengan backend	MR wajib, 1 reviewer, build + lint harus pass
infra-config	Manifest K8s, konfigurasi Nginx, skrip CI/CD	DevOps	Trunk-based, MR ke main	Persetujuan DevOps wajib

15.2 Coding dan Design Standards

Area	Standard / Tool	Enforcement
Language style	[ISI DI SINI -- Style guide / Linter / Formatter]	Pre-commit / CI
Architecture boundaries	[ISI DI SINI -- Rules / Static analysis]	CI / Review
Dependency policy	[ISI DI SINI -- Approved sources / Versions]	SCA / Lockfile
Documentation	[ISI DI SINI -- Public API / Comments / ADR / Changelog]	Review
Testing	[ISI DI SINI -- Unit / Integration / Contract / Coverage]	CI gate

CONTOH:

Area	Standard / Tool	Enforcement
Language style	Go: gofmt + golangci-lint. React: ESLint + Prettier	Pre-commit hook + CI pipeline
Batasan arsitektur	Aturan layer: Handler tidak boleh import Repository. Lintas modul hanya melalui Service.	Checklist code review + custom linter rule
Kebijakan dependensi	Go: lockfile go.sum, tanpa replace directive di production. JS: package-lock.json, alert Dependabot	SCA scan di CI, Dependabot auto-PR
Dokumentasi	Public API: Swagger/OpenAPI auto-generate dari code comment. ADR: markdown di repo /docs/adr/	Checklist review
Testing	Test coverage unit >= 70%. Integration test untuk setiap API endpoint. Tanpa mocking DB di integration test.	CI gate: laporan coverage, test harus pass

15.3 CI/CD Pipeline Controls

Stage	Control	Tool / Method	Failure Policy	Evidence
Commit / PR	Formatting, linting, unit tests, secret scan	[ISI DI SINI]	Block merge	Pipeline
Build	Reproducible build, dependency lock, artifact signing	[ISI DI SINI]	Fail build	Artifact
Security	SAST, SCA, container/IaC scan	[ISI DI SINI]	[ISI DI SINI -- Severity gate]	Report
Deploy	Approval, provenance, environment policy	[ISI DI SINI]	Block deployment	Audit

CONTOH:

Stage	Control	Tool / Method	Failure Policy	Evidence
Commit / PR	Pengecekan format, lint, unit test, scan secret	gofmt + golangci-lint (BE), ESLint + Prettier (FE), gitleaks (secrets)	Blokir merge jika ada check gagal	Status pipeline GitLab CI
Build	Build reproducible, dependency lock, tag Docker image berdasarkan git SHA	go build dengan go.sum, npm ci dengan lockfile, docker build --tag sha-abc123	Build gagal → artefak tidak dipublikasi	Docker image di registry + build log
Security	SAST, SCA, scan container	gosec (SAST), npm audit (SCA), trivy (container)	Blokir jika ada temuan Critical/High. Medium → tiket, lanjutkan.	Laporan scan dilampirkan ke pipeline
Deploy	Persetujuan PM + Tech Lead untuk production	GitLab manual approval gate	Blokir deployment tanpa persetujuan	Log audit persetujuan

15.4 Software Supply Chain

Control	Design / Policy
Dependency source	[ISI DI SINI -- Approved registries / Mirrors]
SBOM	[ISI DI SINI -- Format, generation, storage, delivery]
Artifact integrity	[ISI DI SINI -- Signing / Hash / Provenance]
Vulnerability response	[ISI DI SINI -- SLA by severity / Exception process]
Base images	[ISI DI SINI -- Approved, minimal, patched, pinned]
Third-party licenses	[ISI DI SINI -- Scan / Approval / Attribution]

CONTOH:

Control	Design / Policy
Sumber dependensi	Go: proxy.golang.org (default). JS: npmjs.com. Tanpa private registry di Fase 1.
SBOM	Di-generate per build via syft (format CycloneDX). Disimpan bersama Docker image di registry.
Integritas artefak	Docker image di-tag berdasarkan git SHA. Digest image diverifikasi saat deploy.
Respons kerentanan	Critical: patch dalam 48 jam. High: patch dalam 1 minggu. Medium/Low: sprint berikutnya. Exception: ADR + persetujuan Security Lead.
Base image	Go: golang:1.22-alpine (pinned digest). Node: node:20-alpine (pinned). Di-update bulanan.
Lisensi pihak ketiga	Scan go-licenses di CI. Copyleft (GPL) diblokir. MIT/Apache/BSD diizinkan. Dependensi baru memerlukan review Tech Lead.

15.5 Feature Flags dan Runtime Controls

Flag / Control	Purpose	Default	Scope	Owner	Removal Date
[ISI DI SINI]	[ISI DI SINI]	On/Off	Env / Tenant / User	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Flag / Control	Purpose	Default	Scope	Owner	Removal Date
ENABLE_DASHBOARD_V2	Rollout bertahap UI dashboard baru	Off	Per-env (aktif di staging, mati di prod)	FE Lead	Sprint 8 (setelah persetujuan UAT)
ENABLE_CORE_BANKING_INTEGRATION	Gerbang integrasi Core Banking Fase 2	Off	Global	Tech Lead	Release 2.0
MAINTENANCE_MODE	Blokir semua mutasi, izinkan akses read-only	Off	Global (toggle runtime)	DevOps	Permanen (kontrol operasional)
MAX_UPLOAD_SIZE_MB	Batas ukuran upload file yang dapat dikonfigurasi saat runtime	10	Global	DevOps	Permanen (kontrol operasional)

---

16. Verification, Validation, & Traceability

BA QA -- Bagian ini menghubungkan requirement ke desain dan ke evidence verifikasi.

16.1 Design Verification Strategy

Design Area	Verification Method	Owner	Environment	Evidence
Architecture	Review / Prototype / Analysis	[ISI DI SINI]	N/A / POC	Record
API contracts	Contract test / Schema validation	[ISI DI SINI]	CI / SIT	Report
Performance	Load / Stress / Soak	[ISI DI SINI]	Perf env	Report
Security	Threat review / SAST / DAST / Pen test	[ISI DI SINI]	[ISI DI SINI]	Report
Recovery	Restore / Failover / DR exercise	[ISI DI SINI]	[ISI DI SINI]	Report

16.2 Requirements Traceability Matrix (RTM)

Requirement ID	Deskripsi Requirement	SDD Section / Component	Verifikasi	Test / Evidence	Status
FR-001	[ISI DI SINI]	[ISI DI SINI]	Test / Review / Analysis	[ISI DI SINI]	Open / Pass
FR-002	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
NFR-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Requirement ID	Deskripsi Requirement	SDD Section / Component	Verifikasi	Test / Evidence	Status
FR-PAY-001	Submit pengajuan pembayaran	§9.2 Payment Module, §8.4 POST /api/v1/payments	Functional test	TC-PAY-001	Pass
FR-PAY-003	Multi-level approval dengan threshold	§9.2 Payment Module (state machine), §9.3 BR-002	Functional test	TC-PAY-003	Pass
FR-AUTH-001	SSO login via UIM Next-G	§11.3 Authentication, §6.4 Auth middleware	Integration test	TC-AUTH-001	Pass
NFR-PERF-001	Submit pengajuan p95 < 500ms at 500 users	§12.1 Latency Budget	Load test (k6)	LT-PERF-001	Open
NFR-SEC-001	Audit trail immutable, append-only	§11.8 Security Logging, §6.4 Audit Trail	Security review + test	SR-SEC-001	Pass

16.3 Non-Functional Verification Matrix

NFR ID	Target	Test Scenario	Data Volume / Load	Pass Criteria	Evidence
NFR-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

NFR ID	Target	Test Scenario	Data Volume / Load	Pass Criteria	Evidence
NFR-PERF-001	Submit payment p95 < 500ms	500 concurrent user submit pengajuan selama 10 menit	50 req/s sustained	p95 <= 500ms, error rate < 0.1%, CPU < 70%	Laporan k6 LT-PERF-001.html
NFR-PERF-002	Dashboard load p95 < 2 dtk	100 concurrent user memuat dashboard dengan 6 widget	100 req/s sustained	p95 <= 2 dtk, semua widget ter-render	Laporan k6 + Lighthouse
NFR-AVAIL-001	99.5% uptime selama 30 hari	Simulasi pod crash saat peak load	3 replika, matikan 1 pod	Traffic berpindah < 30 dtk, tanpa 5xx selama failover	Laporan chaos test
NFR-SEC-001	Audit log immutable	Percobaan UPDATE/DELETE record audit via SQL dan API	N/A	Semua percobaan ditolak, alert terpicu	Laporan security test

16.4 Design Review Findings

Finding ID	Review Type	Finding	Severity	Owner	Resolution / Status
F-001	Arch / Sec / QA / Ops	[ISI DI SINI]	H / M / L	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Finding ID	Review Type	Finding	Severity	Owner	Resolution / Status
F-001	Architecture	Payment Module dan Reporting Module berbagi tabel DB secara langsung — melanggar batasan modul	M	Tech Lead	Resolved: Reporting membaca via API, bukan akses DB langsung. ADR-005 dibuat.
F-002	Security	JWT secret key disimpan di file .env yang ter-commit ke repo	H	Security Lead	Resolved: Dipindahkan ke K8s Secret, .env dihapus dari repo, git history dibersihkan.
F-003	QA	Tidak ada test coverage untuk edge case state machine approval (reject setelah partial approval)	M	QA Lead	Resolved: 5 test case ditambahkan untuk transisi state machine.
F-004	Ops	Tidak ada alert yang didefinisikan untuk gap audit log — risiko kepatuhan jika tidak terdeteksi	H	DevOps	Resolved: Alert RB-008 ditambahkan (§14.5). Sudah diuji.

16.5 Definition of Design Complete

TIPS: Checklist ini mendefinisikan kapan desain dianggap selesai dan siap untuk implementasi. Seluruh item harus "Pass" sebelum development dimulai.

No	Kriteria	Status	Evidence
1	Semua architecture views konsisten (context, component, data, deployment, security)	Pass / Fail	Review record
2	Semua interface contracts terdefinisi dan disetujui oleh consumer dan provider	Pass / Fail	Contract docs
3	Data model lengkap dengan dictionary, integrity rules, dan migration plan	Pass / Fail	ERD + dictionary
4	Threat model dan security controls terdokumentasi dan di-review	Pass / Fail	Security review
5	NFR memiliki target terukur dan metode verifikasi	Pass / Fail	NFR matrix
6	Deployment dan operational design (monitoring, alerting, runbook) lengkap	Pass / Fail	Ops review
7	RTM menghubungkan semua requirement ke design elements	Pass / Fail	RTM document

---

17. Migration, Cutover, & Transition

DEV PM -- Bagian ini relevan untuk migrasi, modernisasi, atau transisi dari sistem lama. Skip jika tidak relevan (catat di tabel tailoring).

17.1 Transition Scope

Transition Item	Current State	Target State	Owner	Dependency
[ISI DI SINI -- Application / Data / Interface / User]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Transition Item	Current State	Target State	Owner	Dependency
Aplikasi	Spreadsheet legacy + approval berbasis email	Aplikasi web New bjb GIFT	TSG Dev Team	Infrastruktur siap, sign-off UAT
Master Data (Vendor)	File CSV di shared drive	Tabel Vendors di SQL Server	BA + Finance	Pembersihan data oleh Finance sebelum impor
Master Data (GL Codes)	Excel dari Accounting	Tabel GLCodes di SQL Server	BA + Accounting	Pemetaan format disepakati
Akun User	Daftar user manual di Excel	Tabel Users yang disinkronkan dari HCS	DevOps + IT Klien	Akses API HCS tersedia
Proses Approval	Rantai email + tanda tangan fisik	Approval digital multi-level dalam sistem	PM + VP Finance	Business rules final, role sudah ditugaskan
Data Historis	Tetap di sistem legacy	TIDAK dimigrasikan — legacy tetap dapat diakses read-only	IT Klien	Sistem legacy dipertahankan 12 bulan pasca go-live

17.2 Cutover Plan

Step	Activity	Owner	Start / Duration	Entry Criteria	Backout Point
1	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Step	Activity	Owner	Start / Duration	Entry Criteria	Backout Point
1	Bekukan sistem legacy (mode read-only)	IT Klien	D-Day 18:00 / 30 menit	Semua user sudah diberitahu 1 minggu sebelumnya	Buka kembali legacy, batalkan cutover
2	Jalankan migrasi data final (vendor + GL + user)	DevOps + BA	D-Day 18:30 / 2 jam	Legacy sudah dibekukan, skrip migrasi sudah diuji di staging	Rollback migrasi (down script), buka kembali legacy
3	Rekonsiliasi data — verifikasi jumlah baris + checksum	QA + BA	D-Day 20:30 / 1 jam	Migrasi selesai	Jika rekonsiliasi gagal: rollback langkah 2
4	Smoke test — 10 flow kritis di production	QA	D-Day 21:30 / 1 jam	Rekonsiliasi berhasil	Jika smoke test gagal: rollback langkah 2
5	Switch DNS / cutover URL ke sistem baru	DevOps	D-Day 22:30 / 15 menit	Smoke test berhasil, persetujuan PM	Kembalikan DNS ke legacy
6	Pemantauan — periode observasi 24 jam	DevOps + Backend	D-Day 22:45 / 24 jam	Traffic live di sistem baru	Kembalikan DNS jika ditemukan masalah kritis dalam 24 jam
7	Go-Live dikonfirmasi — legacy masuk mode arsip read-only	PM	D+1 22:45	Observasi 24 jam berhasil, zero masalah kritis	N/A — cutover selesai

17.3 Data Reconciliation dan Acceptance

Control	Source Count / Total	Target Count / Total	Tolerance	Result	Owner
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Pass / Fail	[ISI DI SINI]

CONTOH:

Control	Source Count / Total	Target Count / Total	Tolerance	Result	Owner
Vendor records	1.245 rows (legacy CSV)	1.245 rows (Vendors table)	0 (exact match)	Pass	BA
GL Codes	387 rows (Excel)	387 rows (GLCodes table)	0 (exact match)	Pass	BA
User accounts	5.012 (HCS API)	5.012 (Users table)	0	Pass	DevOps
NPWP format validation	—	1.245 records, all 15-digit valid	0 invalid	Pass	QA
Duplicate vendor check	—	0 duplicates by NPWP	0	Pass	QA

17.4 Rollback dan Contingency

Trigger	Decision Authority	Rollback Action	Maximum Decision Time	Communication
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Trigger	Decision Authority	Rollback Action	Maximum Decision Time	Communication
Rekonsiliasi data gagal (selisih jumlah baris > 0)	Tech Lead	Jalankan down migration, buka kembali legacy, kembalikan DNS	30 menit dari deteksi	Email ke daftar stakeholder + grup WA
Smoke test gagal di flow kritis (submit pengajuan atau login)	Tech Lead + PM	Jalankan down migration, buka kembali legacy, kembalikan DNS	30 menit	Email + WA + telepon ke PM
Error rate > 5% dalam 4 jam pertama pasca-cutover	Tech Lead	Kembalikan DNS ke legacy, investigasi root cause	15 menit dari alert	Auto-alert via PagerDuty + WA
User melaporkan kerusakan data / record hilang	PM (eskalasi dari support)	Bekukan sistem baru, investigasi, kemungkinan revert	1 jam dari laporan terkonfirmasi	Update status page + komunikasi langsung ke stakeholder

---

18. Risks, Limitations, & Open Issues

PM DEV -- Dokumentasikan risiko, limitasi, dan item yang masih terbuka. Setiap item HARUS punya owner dan status.

18.1 Design Risk Register

Risk ID	Risiko	Likelihood	Impact	Mitigasi	Owner	Status
R-001	[ISI DI SINI]	L / M / H	L / M / H	[ISI DI SINI]	[ISI DI SINI]	Open / Accepted / Closed

CONTOH:

Risk ID	Risiko	Likelihood	Impact	Mitigasi	Owner	Status
R-001	UIM Next-G API tidak stabil, menyebabkan login failures	M	H	Mock API untuk dev, circuit breaker, health monitoring	Tech Lead	Open
R-002	SQL Server performa menurun pada aggregation query besar	M	M	Materialized views, Redis cache layer, query review per sprint	Backend Lead	Open
R-003	Casbin policy complexity menyebabkan authorization bugs	M	H	POC di sprint 1, unit test coverage > 90% untuk policy, pair review	Backend Lead	Open
R-004	Data migration dari legacy mengganggu go-live timeline	L	H	Migration di-scope out dari SDD ini; terpisah oleh tim DBA	PM	Accepted

18.2 Known Limitations dan Technical Debt

ID	Limitation / Debt	Alasan	Impact	Remediation Plan	Target Release
TD-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

ID	Limitation / Debt	Alasan	Impact	Remediation Plan	Target Release
TD-001	No message queue — async processing via goroutines only	Tim belum berpengalaman dengan MQ; volume Fase 1 masih rendah	Jika volume > 10K txn/hari, goroutine bisa overwhelm	Evaluasi RabbitMQ/NATS di Fase 2	Release 2.0
TD-002	Monolith — semua modul dalam satu binary	Fase 1 prioritas speed-to-market	Scaling per-modul tidak bisa independen	Refactor ke modular boundaries, evaluate split di Fase 3	Release 3.0
TD-003	Report generation synchronous (blocking request)	PDF library tidak mendukung async	Report besar (>50 halaman) bisa timeout	Move to background job + download link notification	Release 1.1

18.3 Open Questions dan TBD Items

ID	Question / TBD	Decision Needed From	Owner	Due Date	Status
TBD-001	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	Open / Closed

CONTOH:

ID	Question / TBD	Decision Needed From	Owner	Due Date	Status
TBD-001	Format API Core Banking — REST atau SOAP?	IT Klien (tim Core Banking)	Tech Lead	Sprint 2	Open
TBD-002	Push DWH — event stream real-time atau batch malam hari?	VP Finance + IT Klien	BA	Sprint 3	Open
TBD-003	Metode MFA — hanya TOTP atau juga SMS OTP?	Security Lead + IT Klien	Security Lead	Sprint 1	Closed (hanya TOTP)
TBD-004	Template PDF laporan — custom atau menggunakan template korporat yang sudah ada?	Tim Finance	BA	Sprint 4	Open

---

19. Maintenance, Evolution, & Decommissioning

DEV PM -- Bagian ini mendokumentasikan model support, versioning, strategi upgrade, dan rencana decommissioning.

19.1 Support dan Ownership Model

Area	Primary Owner	Backup Owner	Support Window	Escalation
Application	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Infrastructure	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Database	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Security	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Area	Primary Owner	Backup Owner	Support Window	Escalation
Aplikasi (BE + FE)	TSG Backend Team	TSG FE Team (cross-trained)	Sen-Jum 08:00-17:00 WIB. On-call: 24/7 untuk SEV1.	SEV1: Tech Lead → PM → Steering Committee
Infrastruktur (K8s, Nginx, Redis)	TSG DevOps	IT Klien (hanya infra)	Sen-Jum 08:00-17:00 WIB. On-call: 24/7 untuk SEV1.	SEV1: DevOps → Tech Lead → IT Klien
Database (SQL Server)	IT Klien DBA	TSG Backend (level query)	Sen-Jum 08:00-17:00 WIB	SEV1: DBA → IT Manager → Steering Committee
Security (insiden, kepatuhan)	TSG Security Lead	IT Klien Security	24/7 untuk insiden keamanan	SEV1: Security Lead → CTO → Steering Committee

19.2 Versioning dan Compatibility

Artifact	Versioning Rule	Compatibility Window	Deprecation Process
API	[ISI DI SINI -- Semantic / Date / Org rule]	[ISI DI SINI]	[ISI DI SINI]
Events / Schemas	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]
Database	[ISI DI SINI -- Migration version]	[ISI DI SINI]	[ISI DI SINI]
Client applications	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Artifact	Versioning Rule	Compatibility Window	Deprecation Process
API	Semantic versioning (v1, v2). Breaking change = versi major baru.	Minimal 2 versi didukung bersamaan (v1 + v2) selama 6 bulan	Header deprecation di respons → pemberitahuan 3 bulan → sunset
Database	Versi file migration: YYYYMMDD_HHMMSS_description.sql	Setiap migration backward-compatible dengan versi kode sebelumnya	Expand-Migrate-Contract untuk breaking change
Frontend SPA	Git tag per release. Tanpa versioning API — selalu terbaru.	N/A (single deployment, auto-updated)	Feature flag untuk rollout bertahap

19.3 Upgrade dan Patch Strategy

Technology / Dependency	Current Version	Upgrade Cadence	End-of-Support Date	Owner
[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Technology / Dependency	Current Version	Upgrade Cadence	End-of-Support Date	Owner
Go	1.22	Setiap 6 bulan (ikuti siklus release Go, lewati release .0)	N/A (Go memelihara 2 versi major terbaru)	Backend Team
SQL Server	2019	Major: evaluasi setiap 3 tahun. Patch: bulanan (Patch Tuesday)	Jul 2030 (extended support)	DBA / IT Klien
React	18.x	Major: evaluasi saat 19+ stabil. Minor: per sprint jika bermanfaat.	N/A (didukung komunitas)	Frontend Team
Kubernetes	1.28	Setiap 6 bulan (ikuti jendela dukungan K8s: N, N-1, N-2)	~Apr 2025 (1.28 EOL) → rencanakan upgrade ke 1.30	DevOps
Node.js (build saja)	20 LTS	Ikuti jadwal LTS. Upgrade saat LTS saat ini memasuki maintenance.	Apr 2026 (Node 20 mulai maintenance)	Frontend Team

19.4 Decommissioning dan Data Exit

Concern	Design / Plan
Trigger for decommissioning	[ISI DI SINI]
Data export	[ISI DI SINI -- Format, scope, validation, recipient]
Data retention dan disposal	[ISI DI SINI -- Rule / evidence]
Integration shutdown	[ISI DI SINI -- Sequence / notification]
Credential dan access revocation	[ISI DI SINI]
Infrastructure destruction	[ISI DI SINI -- Process / evidence]
Final audit dan archive	[ISI DI SINI -- Owner / retention]

CONTOH:

Concern	Design / Plan
Pemicu decommissioning	Penggantian sistem oleh versi baru, atau klien memutuskan kontrak. Keputusan oleh Steering Committee.
Ekspor data	Format: CSV + SQL dump. Cakupan: semua data transaksi + audit log. Validasi: jumlah baris + checksum. Penerima: IT Klien (transfer terenkripsi via SFTP).
Retensi dan pembuangan data	Data transaksi: pertahankan 7 tahun (sesuai regulasi). Audit log: pertahankan 8 tahun. PII: anonymize setelah periode retensi. Bukti: sertifikat penghapusan.
Penonaktifan integrasi	Urutan: (1) Nonaktifkan akses API inbound, (2) Selesaikan async job yang pending, (3) Kirim ekspor DWH final, (4) Beritahu sistem eksternal (UIM, HCS, SMTP), (5) Cabut registrasi OAuth client.
Pencabutan kredensial dan akses	Cabut: API key, service account, kredensial DB, access key MinIO, password Redis. Timeline: dalam 24 jam dari keputusan decommissioning.
Penghancuran infrastruktur	Hapus K8s namespace, decommission VM, wipe volume storage. Proses: DevOps mengeksekusi, IT Klien memverifikasi, PM menandatangani. Bukti: log audit infrastruktur.
Audit final dan arsip	SDD + semua artefak diarsipkan ke DMS klien. Retensi: permanen (kebijakan klien). Pemilik: PM. Rapat serah terima final + dokumen sign-off.

---

Appendix

A. Glossary

Istilah	Definisi
ADR	Architecture Decision Record -- catatan keputusan arsitektur
DTO	Data Transfer Object -- objek untuk transfer data antar layer
ERD	Entity Relationship Diagram -- diagram relasi antar entitas
NFR	Non-Functional Requirement -- kebutuhan non-fungsional
RBAC	Role-Based Access Control -- kontrol akses berbasis peran
SDD	Software Design Document -- dokumen desain perangkat lunak
SLI	Service Level Indicator -- indikator tingkat layanan
SLO	Service Level Objective -- target tingkat layanan
RTM	Requirements Traceability Matrix -- matriks keterlacakan kebutuhan
[ISI DI SINI]	[ISI DI SINI]

B. Diagram References

Diagram	Tool	Link
System Context	[ISI DI SINI]	[ISI DI SINI]
Container / Subsystem	[ISI DI SINI]	[ISI DI SINI]
ERD	[ISI DI SINI]	[ISI DI SINI]
Component Diagram	[ISI DI SINI]	[ISI DI SINI]
Sequence Diagrams	[ISI DI SINI]	[ISI DI SINI]
Deployment Diagram	[ISI DI SINI]	[ISI DI SINI]
Security DFD	[ISI DI SINI]	[ISI DI SINI]

CONTOH:

Diagram	Tool	Link
System Context	Draw.io (exported SVG)	/docs/diagrams/01-system-context.svg
Container / Subsystem	Draw.io	/docs/diagrams/02-container-view.svg
ERD	DBeaver ERD export	/docs/diagrams/03-erd.svg
Component Diagram	Draw.io	/docs/diagrams/04-component-view.svg
Sequence Diagrams	Mermaid (in SDD §9.6)	Inline in document
Deployment Diagram	Draw.io	/docs/diagrams/05-deployment-topology.svg
Security DFD	Draw.io	/docs/diagrams/06-trust-boundaries.svg

C. Related Standards

Kode	Dokumen	Relevansi
TSG-STD-VALIDASI	Aturan Umum Validasi Form	Input validation rules
TSG-STD-AUDIT	Standar Audit Trail	Audit logging design
TSG-STD-SIT	Kategori Temuan Major SIT	Testing against this design
TSG-STD-UTILITY	System Utility Features	Shared system features

D. End-to-End Review Checklist

Area	Acceptance Check	Status	Reviewer Notes
Governance	Metadata, revision history, tailoring, repositori, dan approval lengkap	Pass / Fail / N/A	[ISI DI SINI]
Scope	Batasan eksplisit dan konsisten dengan requirements	Pass / Fail / N/A	[ISI DI SINI]
Drivers	Driver fungsional, quality, regulatory, dan operational teridentifikasi	Pass / Fail / N/A	[ISI DI SINI]
Architecture	Context, component, runtime, data, deployment, dan security views konsisten	Pass / Fail / N/A	[ISI DI SINI]
Components	Tanggung jawab, interface, data ownership, failure handling, observability, dan acceptance terdefinisi	Pass / Fail / N/A	[ISI DI SINI]
Interfaces	Kontrak, authn, error, timeout, retry, versioning, recovery, dan owner terdefinisi	Pass / Fail / N/A	[ISI DI SINI]
Data	ERD, dictionary, integrity, retention, classification, migration, dan recovery terdefinisi	Pass / Fail / N/A	[ISI DI SINI]
Security	Threat model dan kontrol yang testable terdokumentasi; secrets dan data sensitif terlindungi	Pass / Fail / N/A	[ISI DI SINI]
NFRs	Target terukur dan terhubung ke metode verifikasi	Pass / Fail / N/A	[ISI DI SINI]
Deployment	Environment, topologi, resource, network, konfigurasi, dan rollback terdefinisi	Pass / Fail / N/A	[ISI DI SINI]
Operations	Log, metrics, traces, health, alert, backup, dan runbook actionable	Pass / Fail / N/A	[ISI DI SINI]
DevSecOps	Code, pipeline, artifact, dependency, dan supply-chain controls terdokumentasi	Pass / Fail / N/A	[ISI DI SINI]
Traceability	Requirements terhubung ke design elements dan evidence	Pass / Fail / N/A	[ISI DI SINI]
Risk	Open items, limitations, debt, dan accepted risks punya owner dan status	Pass / Fail / N/A	[ISI DI SINI]

E. Tailoring Guide berdasarkan Tipe Proyek

Profil Proyek	Kedalaman yang Dibutuhkan
Aplikasi CRUD internal kecil, sensitivitas rendah	Governance, scope, context, component inventory, API, data model, security/NFR dasar, deployment, operations, dan RTM. Gabungkan bagian detail yang sederhana.
Sistem informasi bisnis-kritis menengah	Gunakan template lengkap dengan context/container/component, sequence kritis, ERD/dictionary, threat model, NFR terukur, deployment, observability, runbook, dan formal gates.
Platform besar atau teregulasi	Template lengkap plus interface control document terpisah, threat model detail, migration spec, DR plan, performance model, security control mapping, dan multiple viewpoints.
Microservices / event-driven	Tekankan service boundaries, data ownership, API/event contracts, compatibility, idempotency, eventual consistency, outbox/saga, tracing, dan operational independence.
Legacy modernization / migrasi	Tekankan current/target views, coexistence, strangler approach, conversion, reconciliation, cutover, rollback, decommissioning, dan dependency retirement.

F. Change Management Reference

Tipe Perubahan	Aksi SDD yang Diperlukan
Koreksi editorial	Patch version dokumen; tidak perlu design review kecuali mengubah makna
Detail implementasi backward-compatible	Update bagian yang terpengaruh dan evidence; engineering review
Interface atau data field baru	Update catalog, contract, dictionary, security/NFR impact, tes, dan RTM
Breaking interface atau schema change	Buat ADR dan compatibility/migration plan; update consumer; re-run affected reviews
Perubahan arsitektur, deployment, atau security boundary	Update views, ADR, threat model, NFR, operations, dan formal reviews
Accepted risk atau limitation	Catat owner, approver, expiry/review date, dan remediation target

G. Quality Gates dan Review Checklist per Tahap

TIPS: Gunakan quality gates ini sebagai checkpoint sebelum melanjutkan ke tahap berikutnya.

Gate	Tahap	Entry Criteria	Review By	Exit Criteria
G1	Architecture Draft	Architecture drivers identified, context/container views drafted	Architect + PM	Views konsisten, driver tercakup, ADRs drafted
G2	Component Design	G1 passed, all components specified with interfaces	Engineering Lead	Component inventory complete, dependency matrix reviewed, layer rules defined
G3	Data & API Design	G2 passed, ERD + API contracts drafted	Data + Integration reviewers	Data dictionary complete, contracts agreed by all consumers
G4	Security & NFR	G3 passed, threat model + NFR targets defined	Security + QA	Controls testable, NFR has pass criteria, no unmitigated High/Critical threats
G5	Operational Readiness	G4 passed, deployment + observability designed	DevOps/SRE	Environments defined, monitoring actionable, runbooks drafted
G6	Final Approval	G5 passed, RTM complete, all findings resolved	All reviewers	SDD baselined, implementation authorized

H. Common Anti-Patterns (Hal yang Harus Dihindari)

Anti-Pattern	Masalah	Solusi
"Aman dan scalable" tanpa angka	NFR tidak terukur, tidak bisa diverifikasi	Definisikan target spesifik: p95 < 800ms, 99.5% uptime, 500 concurrent users
Nama komponen berbeda di diagram berbeda	Inkonsistensi menyebabkan kebingungan implementasi	Gunakan Component Inventory (§6.1) sebagai single source of truth untuk nama
Desain berhenti di kode, tanpa ops	Sistem tidak bisa di-monitor, di-debug, atau di-recover di production	Tambahkan §14 (Observability) dan §13 (Deployment) sebelum implementation
ADR tanpa alternatif	Keputusan terlihat arbitrary, sulit di-challenge atau di-evaluate	Selalu dokumentasikan minimal 2 opsi yang dipertimbangkan + trade-off
Security as afterthought	Vulnerability ditemukan di akhir, costly to fix	Threat model di awal (§11.2), security review di setiap gate
Diagram tanpa legend	Pembaca tidak tahu apa arti garis, warna, atau bentuk	Setiap diagram HARUS memiliki judul, scope, legend, dan versi
Copy-paste dari proyek lain	SDD tidak mencerminkan sistem yang sebenarnya	SDD harus ditulis dari driver proyek ini, bukan template proyek lain

I. Publishing Checklist

No	Item	Status
1	Metadata lengkap (versi, tanggal, pemilik, klasifikasi)	☐
2	Tailoring table (§1.6) terisi — semua omitted sections punya alasan	☐
3	Seluruh [ISI DI SINI] sudah diganti dengan konten aktual	☐
4	Nama komponen konsisten di seluruh dokumen (diagram, tabel, teks)	☐
5	Semua diagram memiliki judul, scope, legend, dan versi	☐
6	RTM (§16.2) menghubungkan semua requirement ke design elements	☐
7	Semua review findings (§16.4) resolved atau explicitly accepted	☐
8	Approval signatures lengkap (§1.3)	☐
9	Dokumen di-commit ke repositori terkontrol (§1.1 Lokasi Repositori)	☐

---

Hanya digunakan untuk kalangan internal PT. Tristar Surya Gemilang dan tidak untuk didistribusikan secara umum.