Files Service — Scorecard Kajian

DB-13 · SV-13 — 0 tabel metadata — pemilik object storage (Blob). Diagram: Helicopter View · Detail SV-13/DB-13.

Fitur: Upload/Update/Delete, Serve Publik (CDN, 7 tipe), Serve Privat (proxy authenticated, 4 tipe)

✅ Kandidat terakhir dari 13 yang dinilai dalam kajian ini.

Database tetap kosong — keputusan sadar

SV-13 murni non-relational (0 tabel) — Scorecard Database (DB1-DB7) dirancang untuk data relasional (FK, aggregate, dst). Metadata file (URL/filename) disimpan di tabel domain pemiliknya masing-masing (Banner di SV-05, Product Image di SV-01, dst.), bukan di SV-13 sendiri. User memutuskan: tetap dikosongkan (service-only), bukan diadaptasi paksa ke kriteria relasional.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	2	IStorageService (interface bersih: Create/Read/Update/Delete/GetUrl), 3 implementasi pluggable (AzureBlobStorageService/LocalFolderStorageService/NoneStorageService, dipilih via config switch StorageOptions.Provider) — dipakai ~50 titik panggilan lintas hampir semua domain lewat interface, bukan akses SDK langsung.
J2	Independent Scalability	1	Tidak ada data APM riil, pola sama semua kandidat lain.
J3	Fault Isolation (blast radius)	1	Beberapa alur transaksional wajib sukses file operation (Upload PO untuk ZOR, Invoice Evidence untuk SV-08) — blast radius menembus domain lain kalau storage down.
J4	Team Ownership (Conway)	1	Ditanya langsung ke user (wajib) — tidak ada testimoni tim terpisah.
J5	Technology Divergence	0	Meski konsepnya “CDN/object storage”, teknologi dasarnya tetap Azure Blob — tidak ada stack benar-benar baru.
J6	Bounded Context (DDD)	2	Klasifikasi 2 kelas jelas: public CDN 7 tipe vs private authenticated 4 tipe.
J7	Compliance / Security Isolation	2	2 kelas berbeda (public vs private) lahir dari pertimbangan keamanan eksplisit — dokumen sensitif sengaja tidak masuk public CDN.
J8	Independent Lifecycle Data	1	File tidak punya siklus hidup independen — dikontrol tabel domain pemilik masing-masing, SV-13 cuma penyimpan pasif. Kasus ProfilePicture (di bawah) bahkan bypass total dari abstraksi ini.
	TOTAL	10 / 16

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ✅ SPLIT (persis di ambang bawah)

---

Scorecard Database (maks 14)

⚠️ Tetap kosong — keputusan sadar user (2026-07-28): kandidat ini dinilai service-only, kriteria relasional DB1-DB7 tidak diterapkan paksa ke object storage.

---

Temuan tambahan (sesi validasi 2026-07-28)

🔴 F10 diperkuat: ProfilePicture konsisten dikecualikan dari SELURUH method AzureBlobStorageService (Create/Read/Delete/GetUrl) — bukan cuma bug GetUrl (F9 lama). UpdateProfilePictureCommandHandler (SV-12) tidak pernah memanggil IStorageService sama sekali — cuma menyimpan nama file ke tblM_Customer_Image. ProfilePicture memang didesain lewat jalur terpisah (disk lokal, F10) — pola struktural, bukan bug satu fungsi.

---

Rekomendasi Akhir

SPLIT (service) — persis di ambang bawah, turun dari placeholder 14/16 tapi tidak berbalik kelas. Database dinilai tidak relevan untuk kandidat non-relational ini — keputusan sadar, bukan gap.

---

🏁 Milestone kajian

SV-13 adalah kandidat terakhir dari 13 yang divalidasi ketat kriteria-per-kriteria. Lihat Overview untuk rekap skor seluruh kandidat — 4 dari 13 kandidat berbalik ke TUNDA dari status placeholder awal (SV-03/SV-05/SV-07 di Service, SV-09 di Database, SV-12 di kedua sumbu).