A set of rules for organising a domain layer by business areas such as users, orders, and products. The domain layer contains core business concepts and rules; DDD, or domain-driven design, is an approach that structures software around those business areas.
A set of rules for the infrastructure layer, the part of an application that talks to databases and outside services. It describes repositories, external API clients, gRPC-related code, error handling, retries, and query performance.
A set of rules for the presentation layer, the part of an application that receives API requests and sends responses. It covers controllers, request and response conversion, validation boundaries, and error handling for a Go gRPC service.
A set of rules for a use-case layer: the part of an application that runs business operations and connects the user interface with the domain layer. It also defines transaction boundaries, data-transfer objects, validation, errors, and dependency injection.
A description of a Go service organized with clean architecture, where business rules, application actions, outside-system connections, and API handling are kept in separate layers. It uses gRPC, MySQL, Docker, Go Modules, and Protocol Buffers.
Project-wide rules for how a coding assistant should analyze and edit code, including response language, formatting, uncertainty, links, and reporting changes. The excerpt is written in Japanese but asks the assistant to respond politely in Japanese.
A set of coding rules for Go, a programming language often used for backend services and command-line tools. The rules cover formatting, naming, errors, interfaces, context, and dependency injection.
A Go testing rule that defines how to name test files and functions and how to structure tests. Table-driven tests keep several inputs and expected results in one list, then run each case separately.