Clean​ ​Architecture​ ​คือ​อะไร​ ​และ​เหมาะ​กับ​ทุก​โปร​เจ​กต์​หรือ​ไม่

Clean Architecture เป็นแนวคิดจัดส่วนประกอบให้กฎธุรกิจสำคัญไม่ผูกแน่นกับ UI ฐานข้อมูล หรือ Framework ภายนอก เป้าหมายคือเปลี่ยนรายละเอียดเหล่านั้นได้โดยไม่ต้องเขียนกฎใหม่ทั้งหมด แต่ไม่ได้หมายความว่าทุกโครงการต้องมีหลายชั้น Interface และ Factory ตั้งแต่วันแรก

หลักของทิศทาง Dependency

ส่วนที่เป็นนโยบายธุรกิจควรรู้จักแนวคิดของงาน เช่น คำขอและกฎอนุมัติ มากกว่ารู้จักชื่อไลบรารีฐานข้อมูล หากกฎต้องอ่านข้อมูล อาจพึ่งสัญญาที่ชัดแล้วให้ส่วนภายนอกทำหน้าที่เชื่อมจริง อย่างไรก็ตาม การสร้างชั้นนามธรรมจะคุ้มเมื่อช่วยทดสอบ เปลี่ยน หรือแยกความรับผิดชอบได้จริง ไม่ใช่เพราะแผนภาพตัวอย่างมีครบทุกวง

ภาพที่ 1: แนวคิดหลักคือไม่ให้กฎธุรกิจขึ้นกับรายละเอียดที่เปลี่ยนบ่อยโดยไม่จำเป็น

ตัวอย่างสมมติ: ระบบคำนวณค่าบริการ

กฎคิดค่าบริการตามประเภทงานและส่วนลดควรทดสอบได้โดยไม่เปิดเว็บหรือฐานข้อมูลจริง ส่วนการอ่านราคาและบันทึกใบเสนอราคาอยู่ที่ขอบระบบ ถ้าโครงการมีเพียงหน้าฟอร์มหนึ่งหน้าและกฎคำนวณไม่ซับซ้อน การสร้างหลาย Layer อาจเพิ่มต้นทุนมากกว่าประโยชน์ แต่เมื่อกฎเดียวกันถูกเรียกจากเว็บ งานเบื้องหลัง และ API ภายนอก การแยกกฎยิ่งมีเหตุผล

เกณฑ์ว่าใช้มากแค่ไหน

ถามว่ากฎเปลี่ยนบ่อยหรือไม่ มีหลายช่องทางเรียกใช้ไหม การทดสอบส่วนสำคัญต้องแยกโครงสร้างพื้นฐานหรือไม่ และทีมเข้าใจขอบเขตหรือเปล่า หากยังไม่มีปัญหา เริ่มจากโมดูลชัด ๆ และทดสอบกฎที่สำคัญก่อน เมื่อความซับซ้อนจริงปรากฏจึงเพิ่มชั้นที่แก้ปัญหานั้น

สำหรับรายงาน

แสดงกฎหลักกับรายละเอียดภายนอกหนึ่งกรณี อธิบายทิศทาง Dependency และเหตุผลที่ใช้หรือไม่ใช้ชั้นแยกในบริบทโครงการ อย่าเรียกโค้ดว่า Clean Architecture เพียงเพราะมีโฟลเดอร์ชื่อ domain ถ้ากฎยังพึ่ง Framework ทุกจุด

อ่าน Layered Architecture และ Monolith กับ Microservices หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ระบบอนุมัติที่อาจเปลี่ยน UI หรือฐานข้อมูลในอนาคต และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ แผน dependency จาก adapter ไปสู่กฎธุรกิจและ contract ที่จำเป็น ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ กฎอนุมัติทดสอบได้โดยไม่เปิดฐานข้อมูลจริง ส่วนข้อจำกัดที่ต้องระบุคือ การเพิ่ม interface ทุกจุดก่อนมีการเปลี่ยนจริงทำให้ระบบซับซ้อน หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• Microsoft Learn: Common web application architectures — ตัวอย่างการจัด Dependency และขอบเขตงาน