This is a Todo application implemented in Go language following the Clean Architecture principles.
The project follows Clean Architecture principles, decoupling business logic from external dependencies to improve code testability and maintainability.
.
├── cmd # Application entry points
│ ├── gen # Data model generation tools
│ └── server # Main application server
├── config # Configuration files and related functionality
├── database # Database migrations and table definitions
│ └── migration # Database migration scripts
├── internal # Internal code
│ ├── adaptor # Interface definitions between layers
│ ├── delivery # External input layer (REST API)
│ ├── entity # Domain entities
│ ├── repository # Data persistence layer
│ └── usecase # Business logic layer
├── infrastructure # Infrastructure code
└── pkg # Shared utilities and functions
- Go 1.24
- Uber FX (Dependency Injection Framework)
- GORM (ORM Framework)
- SQLite (Database)
- Goose (Database Migration Tool)
This project uses Clean Architecture design pattern, dividing the application into the following layers:
- Entity Layer: Contains business entities and business rules
- UseCase Layer: Contains application-specific business rules
- Repository Layer: Responsible for data persistence
- Delivery Layer: Handles external requests and responses
- Create todos
- List todos (filterable by completion status)
- Update todos
- Delete todos
- Pagination functionality
- Go 1.24 or higher
- Goose (for database migrations)
- Clone the project:
git clone [YOUR_PROJECT_URL]
cd clean_architecture- Install dependencies:
go mod download- Run database migrations and start the application:
make run- Generate data model code (if needed):
make gen- Run database migrations:
make migrate.up- Rollback database migrations:
make migrate.down| Method | Path | Description |
|---|---|---|
| POST | /todos | Create a todo |
| GET | /todos | Get list of todos |
| PUT | /todos/{id} | Update a todo |
| DELETE | /todos/{id} | Delete a todo |
- cmd: Contains main program entry points
- config: Application configuration settings
- database: Database-related files
- internal: Internal application code, not accessible externally
- adaptor: Interface definition layer, defines interaction interfaces between layers
- delivery: Handles HTTP requests and responses
- entity: Business entity definitions
- repository: Data access layer
- usecase: Business logic layer
- pkg: Function libraries that can be referenced by external projects
To add new features, it is recommended to follow this order:
- Define entities in
internal/entity - Define interfaces in
internal/adaptor - Implement data access layer in
internal/repository - Implement business logic in
internal/usecase - Implement API endpoints in
internal/delivery
Testing framework not yet implemented.
Pull requests and issue discussions for problems or feature suggestions are welcome.
Please specify your license terms.