← Secure by Design

Phase 2: Deliberate Refactoring Katas

สัปดาห์ที่ 3–5 · Day 15–35 · 21 วัน เพื่อแปลงทฤษฎีให้เป็นทักษะการเขียนโค้ดที่ปลอดภัย

Week 3 · Kata 1 — Primitive Obsession Breakdown

Day 15–21

เป้าหมาย: สกัด Primitive Types ดิบ (String, int, double) ในคลาสยักษ์ใหญ่ให้กลายเป็น Domain Primitives ที่การันตี Invariants ตั้งแต่วินาทีที่สร้างขึ้น

Day 15

Kata 1: Primitive Obsession Breakdown

  • สำรวจ Legacy Codebase ในคลาส UserProfile และ OrderRequest แล้วชี้จุดที่เป็น Primitive Obsession
เปิดบทเรียน →
Day 16

Kata 1: Complete Domain Primitive Suite

  • วางชุด Domain Primitives ให้ครบ ทั้ง EmailAddress, PhoneNumber, Money และ Quantity
เปิดบทเรียน →
Day 17–18

Validation Pipeline Construction

  • ฝัง Validation Pipeline 5 ขั้น (Origin, Size, Lexical, Syntax, Semantics) ไว้ใน Constructor ของแต่ละ Domain Primitive
  • บังคับใช้หลักการ Fail-Fast: โยน Exception ทันทีที่เจอข้อมูลเสีย
กำลังจะมา
Day 19–20

4D Security Testing & Mutation Testing

  • เขียน Security-Style Unit Tests 4 มิติ (Normal, Boundary, Invalid, Extreme Input / ReDoS)
  • รัน Mutation Testing (PITest / Stryker) เพื่อยืนยันว่า Test Suite สังหารมิวแทนท์ได้เกิน 90%
กำลังจะมา
Day 21

Signature Refactoring & Integration

  • ปรับ Method Signatures ของระบบเดิมให้รับเฉพาะ Domain Primitives เพื่อกัน Parameter Swapping
  • บันทึกแพตเทิร์นการสกัดข้อมูลลง Checksheet ส่วนตัว
กำลังจะมา

Week 4 · Kata 2 — Anemic Domain Model to Secure Aggregate Root

Day 22–28

เป้าหมาย: รื้อคลาสที่มีแต่ Getters/Setters ให้กลายเป็น Secure Aggregate Root ที่ควบคุม State Integrity และสยบ Escaping References

Day 22–23

Eliminating Public Setters

  • ลบ Public Setters ทั้งหมดในคลาส OrderAggregate
  • เปลี่ยนมาใช้ Domain Operations ที่สื่อความหมายทางธุรกิจ เช่น addItem(), cancelOrder(), applyDiscount()
กำลังจะมา
Day 24–25

Escaping Reference Hardening

  • ปิดจุดรั่วของ Collections ด้วย Collections.unmodifiableList(...) หรือ Read-Only Views
  • กันไม่ให้ภายนอกสั่ง .clear() หรือดัดแปลงข้อมูลภายในโดยข้ามการตรวจ
กำลังจะมา
Day 26–27

Invariant & Encapsulation Testing

  • เขียน Unit Tests พิสูจน์ว่าดัดแปลง State จากภายนอกไม่ได้ทุกกรณี
  • ทดสอบ State Integrity เมื่อสถานะเปลี่ยนข้ามหลาย Entities ภายใน Aggregate
กำลังจะมา
Day 28

Milestone Gate 2 Review

  • ตรวจว่าทุกการเปลี่ยนแปลงต้องผ่าน Aggregate Root เท่านั้น แล้วบันทึกเป็นสถาปัตยกรรมตัวอย่าง
กำลังจะมา

Week 4–5 · Kata 3 — State Machine & Entity Relay Refactoring

Day 29–32

เป้าหมาย: สยบ if-else เช็กสถานะที่ซ้อนกันหลายชั้น ด้วย Entity Relay ที่ส่งไม้ต่อข้ามคลาส

Day 29–30

State Decomposition

  • แกะตรรกะ if-else ของสถานะ DRAFT, PAID, SHIPPED, CANCELLED
  • แยกเป็นคลาสตามสถานะ เช่น DraftOrder, PaidOrder, ShippedOrder
กำลังจะมา
Day 31–32

Relay Method Implementation & Compile-time Safety

  • สร้าง Relay Methods เช่น PaidOrder pay(PaymentReceipt receipt) ให้เปลี่ยนสถานะได้เฉพาะขั้นตอนที่ถูกต้อง
  • เขียน Unit Tests พิสูจน์ว่าข้ามสถานะไม่ได้ตั้งแต่ตอนคอมไพล์: ถ้ายังไม่จ่ายเงิน จะไม่มีเมธอดส่งของให้เรียก
กำลังจะมา

Week 5 · Kata 4 — Read-Once Sensitive Data Protection

Day 33–35

เป้าหมาย: ปกป้องข้อมูลความลับ (Password, Sensitive Tokens) ไม่ให้รั่วลง Log และทำลายทิ้งในหน่วยความจำทันทีหลังใช้งาน

Day 33

Read-Once Object & Log Masking

  • สร้างคลาส Password หรือ SecretToken โดยใช้ char[] แทน String
  • Override toString() ให้คืนเฉพาะค่าที่ปิดบัง (********) เพื่อกัน Log Leakage
กำลังจะมา
Day 34

Memory Wiping & Log Audit Testing

  • ล้างหน่วยความจำด้วย Arrays.fill(chars, (char) 0) ทันทีหลังใช้งานเสร็จ
  • เขียนเทสอัตโนมัติสแกนไฟล์ Log เพื่อยืนยันว่าไม่มี Plaintext รั่วออกไป
กำลังจะมา
Day 35

Phase 2 Retrospective & Portfolio Packaging

  • รวมซอร์สโค้ด Kata Solutions ทั้งหมดลง GitHub Repository ส่วนตัว
  • สรุป Checksheet และเตรียมก้าวเข้าสู่ Phase 3: Legacy Refactoring & Real-World Trade-offs
กำลังจะมา