Layered​ ​Architecture​ ​คือ​อะไร​:​ ​Controller​,​ ​Service​ ​และ​ ​Repository​ ​มีหน้า​ที่​อย่างไร

Layered Architecture จัดโค้ดตามความรับผิดชอบเพื่อให้คำขอหนึ่งไหลผ่านส่วนที่มีหน้าที่ชัด เช่น Controller รับ HTTP Request และตอบผล Service จัดกฎของงาน และ Repository ติดต่อฐานข้อมูล รูปแบบนี้เป็นแนวทาง ไม่ใช่ข้อบังคับว่าทุกฟังก์ชันต้องมีสามไฟล์เสมอ

เส้นทางของคำขอ

ตัวอย่าง POST /requests: Controller อ่านข้อมูลและจัด Response, Service ตรวจว่าผู้ใช้เปิดคำขอชนิดนี้ได้และกำหนดสถานะเริ่ม, Repository บันทึกข้อมูล การตรวจสิทธิ์และความถูกต้องต้องอยู่ในจุดที่ไม่ถูกข้ามเมื่อมี Caller อีกแบบ เช่น งานเบื้องหลัง ไม่โยนกฎธุรกิจทั้งหมดไป Controller เพราะจะทำให้ทดสอบและใช้ซ้ำยาก

ภาพที่ 1: ชั้นงานช่วยแยกเหตุผลที่ต้องแก้ เมื่อเปลี่ยน HTTP กฎธุรกิจ หรือวิธีเก็บข้อมูล

ข้อดีและข้อเสีย

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

ตัวอย่างสมมติ: เปลี่ยนกฎอนุมัติ

เดิมหัวหน้าทีมอนุมัติคำขอได้ทุกจำนวน ต่อมามีเพดานวงเงิน หากกฎอยู่ใน Service จุดเดียว การแก้และทดสอบจะชัดกว่าเมื่อกฎกระจายระหว่างปุ่ม Frontend, Controller และ Query หลายแห่ง Repository ยังคงรับผิดชอบอ่าน/เขียนข้อมูล ไม่ควรตัดสินนโยบายวงเงินโดยไม่มีบริบทของงาน

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

วาด Request หนึ่งเส้นผ่านสามชั้น ระบุอินพุต เอาต์พุต และกฎสำคัญ พร้อมยกตัวอย่างการเปลี่ยน Requirement ที่กระทบชั้นใด แยก Logical Layer ออกจากการ deploy จริง เพราะสามชั้นโค้ดอาจยังอยู่ในแอปเดียว

อ่าน Software Architecture และ MVC หรือดู บริการ Web Application

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

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

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

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

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

• Microsoft Learn: Common web application architectures — การจัด Layer และความต่างจาก Tier