Top Golang Architectures

8/25/2025

Top Golang Architectures

Go Architectures

Classic MVC (Model View Controller)

Use cases:

  • Monolith apps
  • For very small microservices (e.g., 1 or 2 endpoints)
  • When speed > structure (PoCs or MVPs)

It's better to at least separate your core logic from your handler (controller) code, to keep future flexibility.

project/
├── main.go                 ← app entry point
├── controllers/            ← Controller: handle HTTP requests
│   └── user_controller.go
├── models/                 ← Model: structs + DB logic
│   └── user.go
├── views/                  ← View: templates (HTML, optional)
│   └── login.html
├── routes/                 ← Routing setup
│   └── router.go
├── database/               ← DB connection setup
│   └── postgres.go

Clean Architecture

Focus: Organize business logic in concentric layers, independent of frameworks and databases.

Principle: Dependencies point inward → UI depends on use cases, use cases depend on entities, infra depends on core.

Use cases:

  • Large systems with evolving requirements
  • Systems where infra/DB may change
  • Enforcing clear separation of concerns
project/
├── cmd/
│   └── server/main.go
├── internal/
│   ├── entity/              ← Core entities (business objects)
│   ├── usecase/             ← Application services (orchestrate business rules)
│   ├── interface/           ← Adapters (controllers, gateways)
│   └── infra/               ← DB, external APIs, etc.
└── pkg/                     ← Shared utilities

Hexagonal Architecture (Ports & Adapters)

Type of clean architecture, but with focus on entry/exit points.

  • Ports (interfaces) = define input/output contracts
  • Adapters = concrete implementations (HTTP, DB, CLI, etc)

Use cases:

  • Apps that must interact with many interfaces (HTTP, gRPC, MQ, CLI)
  • Systems where external layers may frequently change
project/
├── cmd/server/main.go
├── internal/
│   ├── domain/             ← Entities + ports
│   ├── usecase/            ← Business logic
│   ├── delivery/           ← Input adapters (HTTP, gRPC, MQ)
│   └── repository/         ← Output adapters (DB, cache, etc.)

Onion Architecture

Similar to Clean Archi, but emphasizes core domain model at the center.

  • Domain (center): Entities + business rules
  • Application: Coordinates use cases
  • Infrastructure (outer): DB, frameworks, UIs

Use cases:

  • Enterprise systems
  • Business-domain driven apps
project/
├── domain/                 ← Entities (pure Go structs)
├── application/            ← Services (use cases)
├── infrastructure/         ← DB, APIs, frameworks
└── interfaces/             ← Controllers, CLI, gRPC

Feature-based Architecture

Organize by features/modules, not by technical layers.

  • Easier to scale teams (each feature is self-contained)
  • Keeps related code together

Use cases:

  • Mid/large apps with many features
  • Avoiding “fat” shared folders
project/
├── features/
│   ├── user/
│   │   ├── handler.go
│   │   ├── service.go
│   │   └── repository.go
│   ├── product/
│   │   ├── handler.go
│   │   ├── service.go
│   │   └── repository.go

Layered (N-tier)

Traditional presentation → business → data separation.

Use cases:

  • Web apps with simple CRUD
  • When layering discipline is enough (no need for hexagonal/clean complexity)
project/
├── presentation/           ← Handlers, HTTP layer
├── business/               ← Business logic
├── data/                   ← Repositories

Event-driven Architecture

Focus: Services communicate by events/messages instead of direct calls.

  • Loosely coupled
  • Asynchronous
  • Works well with Kafka, RabbitMQ, NATS

Use cases:

  • Microservices systems
  • Real-time pipelines (payments, notifications, analytics)
project/
├── cmd/consumer/
│   └── main.go
├── events/
│   ├── order_created.go
│   └── user_registered.go
├── handlers/
│   └── order_handler.go

CQRS (Command Query Responsibility Segregation)

Separate write model (commands) from read model (queries).

  • Often combined with event sourcing
  • Commands change state, Queries read state

Use cases:

  • High-scale apps
  • Analytics systems
  • Apps with complex read/write requirements
project/
├── cmd/
│   └── main.go
├── commands/               ← Write side
│   └── create_user.go
├── queries/                ← Read side
│   └── get_user.go
└── events/                 ← Domain events

List of Go architectures

  1. Classic MVC
  2. Clean architecture
  3. Hexagonal
  4. Onion
  5. Feature-based
  6. Layered (n-tier)
  7. Event-driven
  8. CQRS

List of Go Frameworks

  1. Gin
  2. Fiber
  3. Echo
  4. Chi
  5. Revel
  6. Beego
  7. Goa
  8. Kratos

Go API Types and Protocols

  1. REST API
  2. gRPC
  3. GraphQL
  4. SOAP
  5. WebSockets
  6. gRPC-Web
  7. Thrift
  8. JSON-RPC / XML-RPC
  9. MQ (RabbitMQ, NATS, Kafka)