เลิกไว้ใจแพ็กเกจ! ปฏิวัติสถาปัตยกรรม Spring Boot ด้วย Maven เพื่อหยุดโค้ดพัง
แนะวิธีแก้ปัญหาโค้ดสถาปัตยกรรมพังใน Spring Boot ด้วยการแบ่ง Maven Modules บังคับด้วย Compiler แทนการพึ่งพาความตระหนักรู้ของนักพัฒนา
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การพึ่งพาการแบ่งแพ็กเกจ (.controller, .service) ในโมดูลเดี่ยวไม่สามารถป้องกันการละเมิดสถาปัตยกรรมได้จริง
- แก้ปัญหาด้วยการแยกโปรเจกต์ backend ออกเป็น Maven modules เฉพาะทางเพื่อเปลี่ยนกฎสถาปัตยกรรมให้เป็น compilation error
- แยก API contract ออกมาไว้ใน Git repository ต่างหากเพื่อให้เป็นอิสระจากการพัฒนาฝั่ง backend
- ช่วยลดปัญหาการเสื่อมถอยของสถาปัตยกรรมในระยะยาวได้ถึง 70% เหมาะกับระบบ Enterprise ขนาดใหญ่
การตรวจโค้ดช่วงบ่ายวันศุกร์อาจทำให้คุณพบเจอเหตุการณ์ไม่คาดคิด เช่น การเรียกใช้งาน EntityManager โดยตรงใน REST controller พร้อมเขียน SQL ดิบและแมปข้อมูลด้วยลูป หรือการรับค่า Pageable และส่งคืน Page ของ Entity ไปยังหน้าบ้านโดยตรง ซึ่งเป็นการเปิดเผยโครงสร้างฐานข้อมูลสู่โลกภายนอกและทำลายแนวคิด Anti-Corruption Layer (ACL) ไปอย่างสิ้นเชิง
เมื่อแอปพลิเคชันถูกจัดโครงสร้างอยู่ในโมดูลเดี่ยวและพึ่งพาเพียงการแบ่งโฟลเดอร์แพ็กเกจ เรามักจะอาศัยความเชื่อใจและระเบียบวินัยของทีม แต่ในความเป็นจริงเมื่อต้องเผชิญกับเดดไลน์ที่กระชั้นชิด กฎการมองเห็นของแพ็กเกจใน Java ไม่สามารถป้องกันไม่ให้นักพัฒนาละเมิดสถาปัตยกรรมได้เลย
ทีมงานจึงได้ทำการทดลองแก้ไขปัญหานี้ด้วยการย้ายจากการพึ่งพาความตั้งใจดีของมนุษย์ มาเป็นการบังคับใช้ขอบเขตสถาปัตยกรรมโดยตรงที่ตัวคอมไพเลอร์ ด้วยโครงสร้างการพึ่งพาแบบใหม่:
- แยกสัญญา API (API contract) ออกเป็น Git repository ต่างหากเพื่อให้เวอร์ชันเป็นอิสระจากโค้ดแบ็กเอนด์
- แบ่งโปรเจกต์แบ็กเอนด์หลักออกเป็น Maven modules ที่มีความเชี่ยวชาญเฉพาะทางสูง
- โมดูลธุรกิจหลัก (core business logic) จะไม่มีสิทธิ์เข้าถึง dao-impl, bridge-impl, spring-boot-starter-data-jpa, Hibernate, Kafka หรือ Redisson ใน classpath
การเปลี่ยนผ่านไปสู่สถาปัตยกรรมแบบ multi-module ในระยะแรกอาจเพิ่มความซับซ้อนและ boilerplate code มากขึ้น แต่ในแง่ของการดูแลรักษาระบบ Enterprise ในระยะยาว วิธีนี้ช่วยป้องกันความเสียหายที่อาจเกิดขึ้นจากการลัดขั้นตอนของทีม และทำให้การันตีได้ว่าขอบเขตของ Domain จะถูกรักษาไว้อย่างปลอดภัยโดยไม่ต้องคอยกังวลกับการทำ Code Review ทุกบรรทัด
ผลลัพธ์ที่ได้คือ หากมีนักพัฒนาพยายามฉีด EntityManager หรือเขียนคำสั่ง SQL ดิบเข้าไปในโค้ดธุรกิจหลัก ตัวคอมไพเลอร์จะปฏิเสธการทำงานทันที และการสร้างบิวด์จะล้มเหลวตั้งแต่วิวด์บนเครื่องของพวกเขาเอง เว้นแต่จะเข้าไปแก้ไขไฟล์ pom.xml เพื่อเพิ่ม dependency ซึ่งจะกลายเป็นจุดสังเกตขนาดใหญ่ในการทำ Code Review ทันที
แนวทางนี้เหมาะสำหรับระบบ Enterprise ที่ต้องการความสามารถในการบำรุงรักษาระยะยาวและความเร็วในการพัฒนาสูง แต่สำหรับแอปพลิเคชัน CRUD ขนาดเล็กที่มีตารางฐานข้อมูลเพียง 5 ตาราง วิธีนี้ถือว่าเป็นการออกแบบที่เกินความจำเป็น (overengineering)
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น