แปลง DDD tactical patterns เป็น code จริง (C#)

ความคืบหน้า0 / 8 บทเรียน

เส้น​ทางการ​เรียน

1. ●01จาก domain กลวงสู่ domain มีชีวิตเริ่มตรงนี้
   • Anemic Domain Modelanti-pattern ที่อ็อบเจ็กต์มีแต่ getter/setter ไร้พฤติกรรม (domain 'กลวง') กฎธุรกิจถูกดึงไปไว้ใน service ทั้งหมด — จ่ายค่า domain model แต่ไม่ได้ประโยชน์ของมันเลย
   • Ubiquitous Languageภาษากลางที่ทีมพัฒนาและผู้เชี่ยวชาญธุรกิจใช้ร่วมกัน อิงกับ domain model โดยตรง คำเดียวกันหมายถึงสิ่งเดียวกัน และสะท้อนลงในชื่อ type/method ใน code
2. ○02Value Object — สร้างค่าที่ "ผิดไม่ได้"
   • Value Objectอ็อบเจ็กต์ที่นิยามด้วย 'ค่า' ไม่มี identity ของตัวเอง สองตัวที่ค่าเท่ากันถือว่าเท่ากัน ควร immutable เช่น Money, Address, Quantity
   • Primitive Obsessioncode smell ที่ใช้ type พื้นฐาน (decimal, string, int) แทนแนวคิดใน domain ที่ควรมี type ของตัวเอง เช่น decimal เปล่าแทนเงิน ทำให้กฎ/หน่วย/การตรวจสอบหล่นหาย — Value Object คือทางแก้
3. ○03Entity กับ identity ที่คงอยู่
   • Entityอ็อบเจ็กต์ที่มี 'ตัวตน' (identity) ต่อเนื่องตามเวลา แม้ค่าภายในเปลี่ยนก็ยังเป็นสิ่งเดิม เทียบกันด้วย id ไม่ใช่ด้วยค่า เช่น Order, OrderLine
   • Identity'ตัวตน' ที่ทำให้ Entity เป็นสิ่งเดิมตลอดอายุแม้ค่าเปลี่ยน เช่น OrderId — ใน code คือการเทียบเท่ากันด้วย id ล้วน ๆ ไม่ใช่ด้วย field ทั้งหมด
4. ○04Aggregate & การรักษา invariant
   • Aggregateกลุ่มของ Entity และ Value Object ที่ถูกมองเป็นหนึ่งหน่วยความสอดคล้อง มีขอบเขตชัดเจน มี root เดียวเป็นประตูเข้า และเป็นหน่วยของ transaction เช่น Order ที่คุม OrderLine
   • Invariantกฎธุรกิจที่ 'ต้องเป็นจริงเสมอ' ภายใน Aggregate เช่น Total ต้องเท่ากับผลรวมของทุกบรรทัด — ต้องถูกต้องภายใน transaction เดียว และ aggregate root เป็นผู้รักษา
5. ○05Order เป็น state machine
   • State Machineแบบจำลองที่อ็อบเจ็กต์มีสถานะจำกัดจำนวนหนึ่ง และเปลี่ยนสถานะได้เฉพาะตามเส้นทางที่กฎอนุญาต เช่น Order: Placed→Confirmed→Preparing→PickedUp→Delivered (+ Rejected/Cancelled) — ห้ามข้ามหรือย้อน
   • Policyกฎเชิงปฏิกิริยา 'เมื่อเกิด X ให้ทำ Y' ใน domain (สติกเกอร์สีม่วงใน Event Storming) เช่น เมื่อร้านไม่ยืนยันภายใน 5 นาที ให้ยกเลิกออเดอร์และคืนเงินอัตโนมัติ
6. ○06Domain Events ใน code
   • Domain Eventสิ่งที่ 'เกิดขึ้นแล้ว' ใน domain ซึ่งส่วนอื่นสนใจ แทนด้วยอ็อบเจ็กต์ immutable ตั้งชื่อเป็นอดีต เช่น OrderPlaced, OrderCancelled — ใช้สื่อสารข้าม aggregate/context
   • Eventual Consistencyความถูกต้องที่ 'ตามมาทีหลัง' ไม่ใช่ทันที ใช้กับการอัปเดตข้าม Aggregate ผ่าน Domain Event แทนการบังคับให้ตรงกันในทันทีภายใน transaction เดียว
7. ○07Domain Service & Specification
   • Domain Serviceบริการที่ถือ 'ตรรกะธุรกิจ' ซึ่งไม่เข้ากับ Entity หรือ Value Object ตัวใดตัวหนึ่งโดยธรรมชาติ ไร้สถานะ (stateless) เช่น PromotionEngine, DeliveryFeeCalculator
   • Specificationpattern ห่อ 'กฎการคัดเลือก/เงื่อนไข' เป็นอ็อบเจ็กต์ที่มี IsSatisfiedBy(...) นำมาประกอบ (and/or/not) และใช้ซ้ำได้ เช่น EligiblePromotionSpec, CancellableOrderSpec
8. ○08Factory & Repository — สร้างของใหม่ กับหาของเก่า
   • Factoryตัวที่ห่อหุ้มตรรกะการ 'สร้าง' Aggregate ที่ซับซ้อน และรับประกันว่าอ็อบเจ็กต์ใหม่ถูกต้องตาม invariant ตั้งแต่แรกเกิด — 'สร้างของใหม่' (repository หา 'ของเก่า')
   • Repositoryตัวที่ทำให้เข้าถึง Aggregate ราวกับเป็น collection ในหน่วยความจำ ซ่อนรายละเอียดฐานข้อมูล — interface (contract) อยู่วงใน, implementation อยู่ Infrastructure; 1 repository ต่อ1 Aggregate Root