kratos-biz-layer
Generates business logic layer components for go-kratos microservices following Clean Architecture. Creates use cases, repository interfaces, business models, and validators. Use when adding business logic to kratos services.
When & Why to Use This Skill
This Claude skill automates the generation of business logic layer components for Go-Kratos microservices, strictly adhering to Clean Architecture principles. It streamlines the development process by scaffolding use cases, repository interfaces, business models, and validators, ensuring high-quality, decoupled, and maintainable code that follows Go-Kratos best practices and Wire dependency injection standards.
Use Cases
- Case 1: Rapidly scaffolding a new domain entity by generating its complete business layer structure, including use cases and repository interfaces.
- Case 2: Implementing complex domain logic and orchestration while maintaining a strict separation between the service, business, and data layers.
- Case 3: Defining robust business models with integrated validation rules using struct tags to ensure data integrity across microservices.
- Case 4: Automating the setup of dependency injection by generating ProviderSets for Google Wire, reducing manual configuration errors.
- Case 5: Extending existing services with new CRUD operations or business methods while maintaining consistent architectural patterns.
| name | kratos-biz-layer |
|---|---|
| description | Generates business logic layer components (use cases, repository interfaces, business models, validators) for go-kratos microservices following Clean Architecture. Use when implementing domain logic, creating entity CRUD operations, adding validation rules, or orchestrating data access in kratos services. |
Clean Architecture Dependency Rule
The business layer (biz) is the core of Clean Architecture in Kratos microservices:
Dependency Flow: Service → Biz → Data
- Biz defines interfaces that data layer implements
- Biz contains business logic independent of frameworks
- Biz uses domain models not ORM entities
Three Key Components
1. Business Models (internal/biz/models.go)
- Domain entities with validation tags
- Independent of database structure
- Use
validatorstruct tags for validation
2. Repository Interfaces (internal/biz/interfaces.go)
- Define data access contracts
- Implemented by data layer
- Accept/return business models, not ORM entities
3. Use Cases (internal/biz/{entity}.go)
- Orchestrate business logic
- Depend on repository interfaces
- Handle validation, logging, error mapping
Wire Dependency Injection
All constructors must be added to ProviderSet in internal/biz/biz.go:
var ProviderSet = wire.NewSet(NewSymbolValidator, NewSymbolUseCase)
After changes, run make generate to regenerate Wire code.
- Create a new entity (use case + interface + model + validator)
- Add methods to existing use case
- Create standalone validator
- View examples and patterns
Wait for response before proceeding.
| Response | Workflow | |----------|----------| | 1, "create", "new entity", "new" | `workflows/create-entity.md` | | 2, "add method", "add", "extend" | `workflows/add-methods.md` | | 3, "validator", "validation" | `workflows/create-validator.md` | | 4, "examples", "patterns", "help" | `workflows/view-examples.md` |After reading the workflow, follow it exactly.
All domain knowledge in `references/`:Core Patterns: use-case-pattern.md, interface-pattern.md, model-pattern.md Code Style: naming-conventions.md
Additional patterns (error handling, logging, transactions, testing) are covered within use-case-pattern.md.
| Workflow | Purpose | |----------|---------| | create-entity.md | Generate complete biz layer for new entity | | add-methods.md | Add CRUD methods to existing use case | | create-validator.md | Create standalone validator | | view-examples.md | Show patterns and examples | Business layer code is correct when: - Use case struct has repo, log, validator, tm fields - Constructor function returns interface type (not struct) - Methods accept context.Context as first parameter - Validation happens before repository calls - Errors are properly wrapped and logged - Repository interface added to interfaces.go - Business model added to models.go with validation tags - Constructor added to ProviderSet in biz.go - User reminded to run `make generate`