go-architecture

IDE Cursor Rules for Golang Development

Architecture & Structure

1. Clean Architecture

   • Maintain clear separation between layers: domain, repository, usecase, handler
   • Follow dependency rule: inner layers must not depend on outer layers
   • Domain entities should not have dependencies on frameworks or external libraries
   • Use dependency injection for infrastructure dependencies

2. Project Structure

root/ ├── cmd │   ├── app │   └── tools ├── config ├── documents ├── internal │   ├── domain │   │   ├── authentication │   │   ├── shared │   │   │   ├── errors │   │   │   └── valueobjects │   │   └── user │   ├── infrastructure │   │   ├── background │   │   ├── db │   │   │   ├── migrations │   │   │   └── repository │   │   ├── file_storage │   │   ├── filestorage │   │   ├── logging │   │   ├── server │   │   └── temporal │   ├── interfaces │   │   ├── persistence │   │   └── rest │   ├── middleware │   ├── shared │   └── usecases ├── pkg │   └── utils

3. **Domain-Driven Design**
- Model domain entities around business concepts
- Use value objects for immutable concepts
- Implement aggregate roots to maintain consistency boundaries
- Define repository interfaces in the domain layer
- Keep business logic in domain entities or domain services

## Code Quality Principles

4. **SOLID Principles**
- **Single Responsibility**: Each struct/function should have only one reason to change
- **Open/Closed**: Extend behavior through interfaces rather than modification
- **Liskov Substitution**: Interface implementations must be substitutable
- **Interface Segregation**: Prefer small, focused interfaces (1-3 methods)
- **Dependency Inversion**: Depend on abstractions, not concrete implementations

5. **DRY (Don't Repeat Yourself)**
- Extract common functionality into shared packages
- Use middleware for cross-cutting concerns
- Create utility functions for repeated operations
- Implement generic repository patterns where appropriate