(GOLANG) REST API theo kiến trúc Clean Architecture
┌────────────────────────────────────────┐
│ Framework (Gin) │ ◄── handler / transport
└────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ Use Case / Business Rules │ ◄── biz
└────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ Interface Adapters (DB) │ ◄── storage
└────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ Entities / Models │ ◄── model
└────────────────────────────────────────┘
1. Xác định Usecase:
Usecase chứa logic nghiệp vụ, chính là tầng Business, do đó cần xác định API này làm gì, ví dụ API lấy ra Item theo ID (GetItemById).
2. Tạo Model/DTO (Data transfer object)
- Tạo Struct đại diện cho dữ liệu kèm phương thức ánh xạ struct vào bảng tương ứng của cơ sở dũ liệu. -- - Nếu một số trường lặp đi lặp lại cho các bảng thì có thể tách riêng ra một file ở package common để dùng chung ( ví dụ Id, Created At, Updated At...)
- Tạo các Request/Response struct (tạo riêng một package common)
3. Viết Interface và Business Logic cho tầng Storage (tại tầng Biz - Business)
- Sử dụng Composition theo nguyên lý thứ 5 của SOLID nhằm tách biệt tầng Biz và Storage
- Cần phân biệt rõ Logic nghiệp vụ (busines) và Logic ràng buộc dữ liệu:
Ví dụ: Tại tầng Business yêu cầu tạo tài khoản mà trường age >18, nhưng tại database thì age > 0 vì age = 0 hoặc age < 0 thì vô lý.
- Tạo file sql.go tương tác với database cho toàn bộ API
- Phương thức thao tác với Database"
- Kiểm tra ID có tồn tại không
- Khởi tạo các Dependency Injection
- Trả về lỗi hoặc data theo yêu cầu từ lớp Business
Comments
Post a Comment