Design Technique for Enterprise Transaction Design

สรุปแนวคิดสำหรับการออกแบบระบบให้ระบบขนาดใหญ่ (Enterprise) และรองรับข้อมูลธุรกรรม(Transaction) จำนวนมาก โดยต้องการให้ขยายระบบ(Scalability) ได้ในอนาคตครับ

เลือกรูปแบบ Data Modeling

•  Transaction
  • การ Lock แบบ Coarse-Grained Lock ไปทำที่ระดับ App ซะ เพราะ Database ทุกคนใช้ ถ้าไป Lock ก็กระทบชาวบ้าน และถ้าทำที่ App สามารถ Scale ได้
  • ส่วนจะดูว่าใช้แนวคิดไหนในการ Lock มันมีพวก Architectural Tactic ช่วยอยู่แล้ว อย่างในตัว POSA3 มีพวกจัดการ Resource เช่น FIFI / LIFO หรือ Deadine Montomic Scheduling เป็นต้น
  • ถ้าทำ Lock แล้วแยกเป็น App Server อีกตัว ถ้ากลัวล่ม ก็ทำ Cluster สิ แล้ว จริงมันมีพวก Enterpise Intergration Pattern อย่าง Service Grid เข้ามาช่วยครับ ^__^
• ORM vs ER
  • ORM เน้น Denormailization ถ้าจะออกแบบเริ่มที่ Class Diagram ก่อน แล้วค่อยแปลงกลับไปเป็น ER Diagram เพราะปัญหาจุกจิ เช่นการ Lock
  • ตั้งชื่อ Data Schema ให้สอดคล้องกับ Class (จริงถ้ามันไม่ตรงก็มี feature mapping นะ อย่างใน Dapper มี Attribute Column ด้วยนะ เพราะถ้ามี Mapping หมายความว่าต้องมี Cost ที่เสียไปสำหรับการหาว่า Class นี้ใช้กับ Database Column ไหน
• พวก Sensitive Data จัดการอย่างไร
  • แยก Table ออกไป - จัดได้คุมสิทธิ์ได้ง่าย เช่น Table ข้อมูลลูกค้า กับ Table ข้อมูลบัตรเครคิด
  • แล้ว Table ที่แยกไป จัดให้อยู่ในพื้นที่ที่เหมาะสม เช่นไว้ใน Database ที่อยู่ใน Security Zone คนละชั้นสื
  • การจัดการข้อมูล INSERT / UPDATE ต้องเข้ารหัสแบบ One-way
  • ออกแบบย่างไง - ง่ายๆตาม Security Policy ของลูกค้า
• Data distribution / Data Centralization
  • ข้อมูลลูกค้า มีกี่ระบบก็ของใครของมัน ช้อมูลไม่ Sync เอามา Sync สำหรับทำ Data Science พอต้องการเอาข้อมูลมาวิเคราะห์ก็ลำบากมากต้องเสียเวลามารวมข้อมูลอีก
  • ทำเป็น API สิ นั้นแหละ Micro-Service

เลือกรูปแบบ Architectural Patterns

• Half-Sync/Half-Async
• Leader/Followers