Clean Architecture ด้วย .NET

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

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

1. ●01ทำไมต้องมีโครง — จากวงแหวนสู่ 4 projectเริ่มตรงนี้
   • Clean Architectureแนวสถาปัตยกรรมของ Robert C. Martin ที่จัด code เป็นวงแหวนซ้อนกัน (Entities → Use Cases → Interface Adapters → Frameworks) ภายใต้ Dependency Rule เพื่อกัน business rules ออกจาก UI ฐานข้อมูล และ framework
   • Dependency Ruleกฎเดียวของ Clean Architecture: source-code dependency ต้องชี้เข้าด้านในเสมอ วงในห้ามรู้จักวงนอก — ใน code .NET แปลเป็นทิศทางของ ProjectReference ระหว่าง project
2. ○02ชั้น Domain — domain ที่ไม่รู้จักโลกภายนอก
   • Domain Modelแบบจำลองธุรกิจที่รวมข้อมูลและพฤติกรรม (กฎธุรกิจ) ไว้ด้วยกัน อยู่วงในสุดของสถาปัตยกรรมและไม่พึ่งพาสิ่งภายนอกใด ๆ
   • Aggregateกลุ่มของ object ที่ถือเป็นหนึ่งหน่วยความสอดคล้อง (consistency boundary) มี root เดียวเป็นประตูเข้า และคอยรักษา invariant ของทั้งกลุ่ม เช่น Order ที่คุม OrderLine
3. ○03ชั้น Application — use case ด้วย CQRS/MediatR
   • Use Caseกฎธุรกิจเฉพาะ application (application business rule) ที่ประสานการไหลของข้อมูลเข้า-ออก Entities เพื่อทำงานหนึ่งอย่างให้จบ เช่น PlaceOrder — ใน code คือ handler ของ command/query
   • CQRSCommand Query Responsibility Segregation — แยกฝั่ง 'สั่งให้เปลี่ยนสถานะ' (command) ออกจากฝั่ง 'อ่านข้อมูล' (query) เป็นคนละเส้นทาง มักใช้คู่กับ MediatR ใน .NET
4. ○04ชั้น Infrastructure — EF Core & Repository
   • Repositoryabstraction ที่ทำให้ domain เข้าถึง/บันทึก aggregate ได้เหมือนเป็น in-memory collection โดยไม่รู้จักเทคโนโลยีจัดเก็บจริง — interface อยู่วงใน implementation อยู่ Infrastructure
   • Persistence Ignoranceหลักที่ว่า domain model ไม่ควรรู้อะไรเลยเกี่ยวกับวิธีที่มันถูกบันทึกลงฐานข้อมูล ทำให้สลับ ORM/DB ได้โดยไม่แตะกฎธุรกิจ
5. ○05ชั้น Web — API & error handling
   • REPR (Request-Endpoint-Response)รูปแบบจัด API เป็น endpoint ต่อ1 use case ที่รับ Request ทำงาน แล้วคืน Response — เข้ากับ Clean Architecture ดีกว่า controller อ้วนที่รวมหลาย action
   • API Endpointจุดเข้าของ Web layer ที่แปลง HTTP request เป็น command/query ส่งเข้า Application แล้วแปลงผลกลับเป็น HTTP response — เป็น adapter ไม่ใช่ที่อยู่ของกฎธุรกิจ
6. ○06Composition Root — ต่อสาย DI ให้ dependency ชี้เข้าใน
   • Dependency Injectionเทคนิคส่ง dependency (ที่ implement ตาม interface) เข้ามาจากภายนอกแทนที่จะสร้างเอง ทำให้วงในพึ่งพา abstraction ไม่ใช่ของจริง และสลับ/ทดสอบได้ง่าย
   • Composition Rootจุดเดียวใกล้ขอบสุดของ app (ใน .NET คือ Program.cs / DI container) ที่ประกอบ interface เข้ากับ implementation จริง เป็นที่เดียวที่ 'รู้จักทุกอย่าง'
7. ○07test ครั้งแรก — ทำไมสถาปัตยกรรมนี้ test ง่าย
   • Unit Testtest หน่วยเล็กที่สุดแบบแยกตัว รันเร็ว ไม่พึ่ง DB/เครือข่าย — ในสถาปัตยกรรมนี้ domain ทดสอบได้โดยไม่ต้อง mock เพราะมันบริสุทธิ์อยู่แล้ว
   • Testabilityคุณสมบัติที่ระบบถูกทดสอบได้ง่ายโดยเนื้อแท้ — ผลพลอยได้หลักของการกลับทิศ dependency ให้ business rules ไม่ผูกกับ UI/DB/framework
8. ○08เมื่อไร "อย่า" ใช้ Clean Architecture
   • Vertical Slice Architectureแนวจัด code ตาม 'feature' (slice แนวตั้งที่ตัดผ่านทุกชั้น) แทนการแบ่งตามชั้นเทคนิค — ทางเลือกที่เบากว่าเมื่อ Clean Architecture เริ่ม over-engineer
   • YAGNI (You Aren't Gonna Need It)อย่าสร้างสิ่งที่ยังไม่ต้องใช้ — เตือนไม่ให้ใส่ abstraction/ชั้นเกินจำเป็นเพียงเพราะ 'เผื่อไว้'