DEV Community

c_nooknook_daily_prompt
c_nooknook_daily_prompt

Posted on • Edited on

รู้ยัง? โครงสร้าง Spring Boot ที่ดีช่วยให้คุณเขียน API ได้เร็วขึ้น 3 เท่า!

#programming #newbie #beginners #java

Basic/Monolithic Structure (โครงสร้างแบบพื้นฐาน/โมโนลิธิก)
เหมาะกับโปรเจกต์ขนาดเล็กถึงกลาง หรือสำหรับเริ่มต้นเรียนรู้ Spring Boot

src
└── main
    ├── java
    │   └── com.example.demo
    │       ├── controller
    │       ├── service
    │       ├── repository
    │       ├── model
    │       └── DemoApplication.java
    └── resources
        ├── application.properties
        └── templates/
Enter fullscreen mode Exit fullscreen mode

ข้อดี:

  • เรียบง่าย เข้าใจง่าย
  • เหมาะกับโครงการเล็ก

ข้อเสีย:

  • ขยายยากเมื่อระบบใหญ่ขึ้น
  • ความรับผิดชอบของแต่ละส่วนอาจปะปนกัน

Modular/Multi-Module Structure (โครงสร้างแบบแยกโมดูล)

เหมาะสำหรับโปรเจกต์ขนาดใหญ่ หรือทีมงานหลายคน

project-root
├── common         ← โมดูลที่ใช้ร่วมกัน เช่น DTO, Utils
├── user-service   ← โมดูลสำหรับจัดการ user
├── order-service  ← โมดูลสำหรับจัดการ order
├── web            ← โมดูลสำหรับจัดการ Web/API
└── pom.xml        ← รวม dependency ของทุกโมดูล (Parent POM)
Enter fullscreen mode Exit fullscreen mode

ข้อดี:

  • แยกหน้าที่ชัดเจน
  • ทดสอบแยกแต่ละโมดูลได้
  • ดูแลโค้ดง่าย

ข้อเสีย:

  • ซับซ้อนขึ้น
  • ต้องจัดการ dependency และ build มากขึ้น

Hexagonal Architecture (Clean Architecture/Ports & Adapters)
เหมาะกับโปรเจกต์ระดับองค์กรที่เน้นแยกชั้นความรับผิดชอบ (Separation of Concerns) อย่างเคร่งครัด

src
└── main
    ├── java
    │   └── com.example.app
    │       ├── application    ← business logic (use cases)
    │       ├── domain         ← entity, interface
    │       ├── infrastructure ← adapter เช่น JPA, REST client
    │       └── web            ← controller (entry point)
Enter fullscreen mode Exit fullscreen mode

ข้อดี:

  • ยืดหยุ่นและรองรับการเปลี่ยนแปลงสูง
  • เทสได้ง่าย
  • สะท้อนแนวคิด DDD (Domain Driven Design)

ข้อเสีย:

  • ซับซ้อนในการเริ่มต้น
  • ต้องเข้าใจแนวคิด architecture ลึก

Structure ของ test
ควรจัด structure ของ test ให้ "สะท้อน" โครงสร้างของโปรเจกต์หลัก (main code) เพื่อให้ เข้าใจง่าย, ดูแลต่อได้ดี, และ หาไฟล์เทสได้ไว

“ทุก class ที่อยู่ใน src/main/java ควรมี test class ที่สัมพันธ์กันใน src/test/java ด้วยชื่อและ path คล้ายกัน”

โครงสร้างโค้ด + เทสที่ดี

โครงสร้างโปรเจกต์หลัก:

src/main/java/com/example/demo
├── controller
│   └── UserController.java
├── service
│   └── UserService.java
└── repository
    └── UserRepository.java
Enter fullscreen mode Exit fullscreen mode

โครงสร้าง Test ที่สอดคล้องกัน:

src/test/java/com/example/demo
├── controller
│   └── UserControllerTest.java
├── service
│   └── UserServiceTest.java
└── repository
    └── UserRepositoryTest.java
Enter fullscreen mode Exit fullscreen mode

หมายเหตุ:

  • ใช้คำว่า Test ต่อท้ายชื่อคลาส เช่น UserServiceTest
  • วาง test class ให้อยู่ใน package เดียวกับ class จริง (mirror structure)

❌ โครงสร้างที่ไม่แนะนำ

src/test/java
├── AllTestsTogether.java      ← เทสทุกอย่างในไฟล์เดียว
├── testUserService.java       ← ชื่อไฟล์ไม่ชัดเจน
└── randomTest1.java
Enter fullscreen mode Exit fullscreen mode

✅ สรุป ✅

หากคุณกำลังเริ่มพัฒนา Spring Boot ใหม่ ๆ แนะนำเริ่มจาก แบบ Basic ก่อน แล้วค่อยขยับไป Modular หรือ Clean Architecture ตามความซับซ้อนของระบบ

โครงสร้าง เหมาะกับโปรเจกต์ ความง่าย ความยืดหยุ่น ขนาดทีม
Basic เล็ก/กลาง ⭐⭐⭐⭐ ⭐ 1-2 คน
Modular กลาง/ใหญ่ ⭐⭐⭐ ⭐⭐⭐⭐ 3-10 คน
Hexagonal ใหญ่/องค์กร ⭐⭐ ⭐⭐⭐⭐⭐ 50+ คน

"จัดโครงสร้าง test ให้ เหมือนกับโครงสร้างโปรเจกต์หลัก (mirror structure)
เพื่อให้คุณ เขียน/อ่าน/ดูแล/รัน test ได้อย่างเป็นระบบ"

ประโยชน์ รายละเอียด
✅ อ่านง่าย เห็นโค้ดหลักตรงไหน ก็รู้ว่า test อยู่ที่ไหน
✅ จัดการง่าย เวลา refactor โค้ด ก็ย้าย test ไปด้วยได้
✅ รองรับ CI/CD ระบบเทสอัตโนมัติจะรันไฟล์ได้ถูกต้อง

Top comments (0)