kratos-biz-layer

alecszaharia's avatarfrom alecszaharia

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.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 29, 2025

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.
namekratos-biz-layer
descriptionGenerates 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.
## How Kratos Business Layer Works

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 validator struct 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.

What would you like to do?
  1. Create a new entity (use case + interface + model + validator)
  2. Add methods to existing use case
  3. Create standalone validator
  4. 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`