Architecture Overview

This project is a direct implementation of the Clean Architecture principles proposed by Robert C. Martin (Uncle Bob). The primary goal of this architecture is the separation of concerns, which is achieved by dividing the software into layers. This design produces a system that is independent of frameworks, testable, and flexible enough to evolve over time.

Clean Architecture Diagram

The Dependency Rule

The most critical rule of Clean Architecture is the Dependency Rule. This rule states that source code dependencies can only point inwards. Nothing in an inner circle can know anything about an element in an outer circle. Specifically, code in the Domain and Service layers cannot depend on code in the Repository or Delivery layers.

This is achieved through the use of interfaces (in Go's case) at the boundaries between layers. The inner layers define interfaces, and the outer layers provide the concrete implementations.

Project Layers

This project is organized into four distinct layers, which map to the circles in the diagram:

1. Domain Layer

  • Directory: domain/
  • Responsibility: This is the core of the application. It contains the enterprise-wide business models (entities) and domain-specific errors. These are the pure data structures that represent the fundamental concepts of the application, like Article and Author. This layer has zero dependencies on any other layer in the application.
  • Learn more about the Domain Layer

2. Service Layer (Usecases)

  • Directory: article/
  • Responsibility: This layer contains the application-specific business logic. It orchestrates the flow of data by using the domain models. Crucially, it defines the interfaces for its dependencies (like repositories) but does not know about their implementations. For example, the ArticleService defines an ArticleRepository interface that specifies methods like GetByID or Store, but it doesn't know or care if the data is stored in MySQL, PostgreSQL, or a simple text file.
  • Learn more about the Service Layer

3. Repository Layer (Interface Adapters)

  • Directory: internal/repository/
  • Responsibility: This layer acts as a bridge between the business logic (Service Layer) and the data sources. It provides concrete implementations of the repository interfaces defined in the Service Layer. In this project, internal/repository/mysql/ contains the logic for interacting with a MySQL database. This is where SQL queries are executed and data is mapped from database rows to the domain models.
  • Learn more about the Repository Layer

4. Delivery Layer (Frameworks & Drivers)

  • Directory: internal/rest/
  • Responsibility: This is the outermost layer, responsible for presenting data and handling user input. In this project, it's a REST API built with the echo framework. The HTTP handlers in this layer receive requests, parse them, call the appropriate methods on the Service layer, and format the results back into an HTTP response (e.g., JSON). This layer depends on the Service layer but not on any of the layers further in.
  • Learn more about the Delivery Layer

By adhering to this structure, the project remains highly modular. We could swap echo for a different web framework, or replace MySQL with another database, with minimal to no changes required in the core Domain and Service layers.