Volume 11 · Data Model & Persistence
Volume 3-10 อธิบายแต่ละ repo แยกกัน — persistence layer, auth model, integration ก็ถูกบันทึกไว้ในบทของตัวเอง Volume นี้ทำหน้าที่ตรงข้าม — synthesize ข้าม repo ทั้งหมด เพื่อตอบคำถามที่ตอบไม่ได้จากการอ่านทีละ repo: มี datastore กี่ตัวในทั้งแพลตฟอร์ม ใครเป็นเจ้าของ ใคร bypass API แล้วต่อฐานข้อมูลของอีก service ตรง identity ของพนักงานหนึ่งคน "ตัวจริง" อยู่ที่ไหนกันแน่ และ debt ด้าน data integrity ที่กระจายอยู่หลาย repo รวมกันแล้วมีขนาดใหญ่แค่ไหน
Volume นี้ไม่ re-explore โค้ดจากศูนย์ — ทุก fact อ้างอิงกลับไปที่บทที่ deep-dive agent เขียนไว้แล้วใน Volume 3-10 ยกเว้นจุดที่ต้อง cross-check ข้าม repo (เช่น "database ชื่อเดียวกันบน host เดียวกันของสอง repo คนละกลุ่ม") ซึ่งจะ cite file:line ตรงเมื่อ verify เอง
โครงสร้าง Volume 11
Volume 11 · Data Model & Persistence
├── 11.1 Persistence topology inventory ทุก datastore ข้าม ~25 repo
├── 11.2 Cross-service coupling distributed monolith — service ที่ต่อ DB ของ service อื่นตรง
├── 11.3 Identity across systems empCode/userId/idCard ไหลข้าม MariaDB/MSSQL/Mongo/LDAP อย่างไร
├── 11.4 Shared secrets & credentials รวม secret ที่แชร์ข้าม repo เป็นภาพเดียว (blast radius)
└── 11.5 Scorecard debt ID เฉพาะด้าน data (CORR-DATA-*, QUAL-DATA-*)ทำไมต้องมี Volume แยก
Volume 3.1.5 (vtrc-api persistence), Volume 6 (*/03-persistence*.md ของทุก domain microservice), Volume 5/7 (*/03-persistence-integrations.md) แต่ละบทตอบคำถาม "repo นี้เก็บข้อมูลอย่างไร" ได้ดี แต่ไม่มีที่ไหนตอบคำถามระดับแพลตฟอร์ม เช่น
- "ถ้า
vtrc-apiเปลี่ยน schema ตารางWDHospitalsจะกระทบ repo อื่นกี่ตัว" — คำตอบอยู่กระจายใน 3 volume (benefit-api,workflow-api,2way-api) - "ถ้า JWT secret ตัวหนึ่งรั่ว กระทบกี่ service" — คำตอบอยู่กระจายใน
canonical-truths.md+ 4 volume ที่เขียนไม่พร้อมกัน - "พนักงานคนเดียวมีกี่ ID ในระบบทั้งหมด" — ไม่มีที่ไหนรวมไว้เลยนอกจาก v1 Volume 8 (ซึ่ง cover แค่ legacy 5 service)
Volume 11 อุดช่องว่างนี้โดยเฉพาะ ส่วน business logic ของแต่ละ domain อยู่ที่ Volume 14, security ของ auth mechanism (ไม่ใช่ data) อยู่ที่ Volume 12
สรุปข้อค้นพบหลัก (executive summary)
- ไม่มี canonical identity source เดียว — พนักงานหนึ่งคนมีตัวแทนอย่างน้อย 5 รูปแบบข้าม MariaDB (
vtrc-centralize.Users.userIdUUID), MSSQL HRMI (Employee.EmpID/EmpCode), MSSQL domain microservices (empCodestring ซ้ำในทุกตาราง), LDAP (adUsername=crc64(idCard)), และ mobile/frontend token payload — ดู 11.3 - "Distributed monolith" คือ pattern หลัก ไม่ใช่ข้อยกเว้น — อย่างน้อย 6 service ต่อฐานข้อมูลของ service อื่นตรงโดยไม่ผ่าน API:
benefit-api→vtrc,workflow-api→vtrc+benefit+HRMI ×2,pms-api→dbWorkforce,2way-api→pmsschema,chat-center-api→dbHRMI_Center,sso-api→dbHRMI_Center— ดู 11.2 - JWT secret เดียวกันใช้ข้ามอย่างน้อย 4 domain microservice (
benefit-api,recruitment-api,ai-recruitment-api,pms-api) และ MSSQLsapassword เดียวกันใช้ข้ามอย่างน้อย 4 repo อื่น (chat-center-api,job-scheduler-api,vtrc-common,workflow-api) — ดู 11.4 - chat-center-api เขียนเข้า database ชื่อ
2wayบน host เดียวกับ2way-apiพร้อมsynchronize: true— เสี่ยง auto-alter schema ของ database ที่อีก repo คนละกลุ่มเป็นเจ้าของ — ดู 11.2 - Transaction pattern ที่ดูเหมือนทำงานแต่ไม่ทำงานจริง พบซ้ำใน
vtrc-api(arg ที่ 3 ถูก JavaScript drop) และไม่มี transaction เลยใน2way-vtrc-api/meeting-vtrc-apiสำหรับ multi-table insert — ดู 11.5
Evidence source
Volume นี้สังเคราะห์จาก
- Canonical Truths — แหล่งความจริงหลักที่ verify แล้วข้ามทั้ง 25 repo
- ทุกไฟล์
*/03-persistence*.md,*/04-auth-integrations.mdใน Volume 5, Volume 6, Volume 7 vtrc-api/05-persistence.md,03-auth-session.md,04-centralize-bridge.mdใน Volume 3cu-central-api/03-multitenancy-schema.md,02-auth-ldap-directive.mdและcentralize-api/02-rest-service-entities.mdใน Volume 3- ทุกไฟล์
*scorecard*.mdของ Volume 3-9 (27 ไฟล์) สำหรับ debt ที่เกี่ยวกับ data - v1 archive Volume 8 · Data Model สำหรับ pattern การเขียน identity graph (legacy 5 service เท่านั้น — v2 ขยายให้ครอบทั้ง 25 repo)
จุดที่ต้อง cross-check เองข้าม repo (ไม่มีบทใดเขียนไว้ตรง ๆ) จะ cite file:line ตรงพร้อม branch annotation
ไปเริ่มที่ 11.1 Persistence topology →