Go Microservices Architecture Best Practices Based on Clean Architecture and trpc-Go

This article explores Go microservices architecture practices using the trpc-Go framework, addressing common challenges in code organization and maintainability.

Current Development Problems:

Most microservices suffer from: (1) lack of reasonable package division or only logical responsibility division; (2) procedural programming with long function call chains; (3) no dependency injection with global imports causing potential concurrency issues. These lead to poor maintainability, difficult test writing, and unclear data flow.

Clean Architecture Solution:

The article proposes a pyramid-style architecture based on trpc-Go directory specifications with four layers: gateway (interface implementation, protocol parsing without business logic), logic (core business logic with modular packages), repo (external dependencies including databases and RPC calls with abstract interfaces), and entity (shared data structures, constants, error codes using anemic model).

Implementation Specifications:

1. Dependency Inversion & Interface Segregation: Upper modules should not depend on lower modules; both should depend on abstractions. Interfaces should be minimal and stored separately from implementations.

2. Dependency Injection: Internal dependencies should be injected from outside rather than created internally, reducing coupling and enabling easier testing.

3. Testing Standards: Use gomock instead of monkey patching. If monkey mock is needed, the code doesn't follow interface principles. Gomock stubs can be auto-generated and injected as dependencies.

4. Configuration Management: Each service should have one remote configuration (JSON format) defined in entity/config package. Interface-based configuration enables dependency injection and reduces configuration scope to avoid concurrency issues.

Implementation Phases:

The article suggests a three-phase approach: (1) Basic directory organization; (2) Layer separation and dependency injection; (3) Complete standardization. This allows teams to adopt incrementally without disrupting development velocity.

Why Not DDD:

While DDD is powerful for medium-to-large projects, it requires upfront domain modeling that isn't practical for new services with unclear boundaries. The proposed architecture provides consistency and maintainability without the complexity of DDD, making it easier for new team members to adopt. When services grow large enough, DDD refactoring can be considered as an alternative solution.