How to properly structure the service architecture: where to store commands, domain entities, errors?

The proper architecture structure of a service in Go is usually built around the principles of clean architecture and separation of concerns:

• Domain Entities:

  • Store business logic and state.
  • Usually located in a separate domain package.
  • Do not depend on infrastructure or external libraries.

• Commands:

  • Represent actions or operations that can be performed on domain entities.
  • Often implemented as separate structs or interfaces in the application layer, which call methods of domain entities.

• Errors:

  • Better defined in the context where they occur.
  • For domain errors — in the domain package, so that business logic can handle them.
  • For infrastructural errors — in the respective packages.
  • Use error types and wrappers for ease of handling and passing information.

Example package structure:

/service
  /domain
    entity.go
    errors.go
  /application
    commands.go
  /infrastructure
    repository.go
    errors.go

This approach ensures architecture purity, facilitates testing, and supports code maintenance.