Go言語のレイヤードアーキテクチャの仕組みと実装例！初心者でもわかる階層設計ガイド

Go言語のレイヤードアーキテクチャの仕組みと実装例

先生と生徒の会話形式で理解しよう

生徒

「Go言語でWebアプリを作っているんですが、コードがどんどん混ざってきて分かりにくくなってきました。レイヤードアーキテクチャっていうのが良いって聞いたんですが...」

先生

「レイヤードアーキテクチャは、プログラムを層に分けて整理する設計手法です。各層の役割を明確にすることで、コードが整理されて管理しやすくなりますよ。」

生徒

「層に分けるって、具体的にはどういうことですか?」

先生

「それでは、レイヤードアーキテクチャの基本的な仕組みから、実際のGo言語での実装方法まで、詳しく見ていきましょう！」

1. レイヤードアーキテクチャとは？

レイヤードアーキテクチャとは、プログラムを複数の層（レイヤー）に分けて設計する手法です。英語でLayered Architectureと呼ばれ、日本語では階層型アーキテクチャとも言います。

例えるなら、ケーキのように層が重なっている構造です。スポンジケーキには、スポンジ、クリーム、フルーツなど、それぞれ違う役割の層がありますよね。プログラムも同じように、それぞれ異なる役割を持つ層を重ねて作ります。

レイヤードアーキテクチャでは、一般的に3つから4つの層に分けます。最も一般的な構成は、プレゼンテーション層、ビジネスロジック層、データアクセス層の3層です。それぞれの層は独立した責任を持ち、上の層は下の層を使いますが、下の層は上の層のことを知りません。

この設計手法の最大のメリットは、それぞれの層が独立しているため、1つの層を変更しても他の層への影響が最小限に抑えられることです。例えば、データベースをMySQLからPostgreSQLに変更する場合、データアクセス層だけを修正すれば済みます。

2. レイヤードアーキテクチャの3つの基本層

レイヤードアーキテクチャを構成する基本的な3つの層について、それぞれの役割を詳しく見ていきましょう。

プレゼンテーション層（表示層）

ユーザーとのやり取りを担当する層です。Webアプリケーションの場合、HTTPリクエストを受け取り、HTMLやJSONの形式でレスポンスを返します。Go言語では、ハンドラー関数やコントローラーがこの層に該当します。ユーザーからの入力を受け取り、ビジネスロジック層に処理を依頼し、その結果を表示する役割を担います。

ビジネスロジック層（サービス層）

アプリケーションの中核となる処理を担当する層です。業務ルールや計算処理など、アプリケーション特有のロジックを実装します。例えば、ユーザー登録時のバリデーション、在庫の計算、注文処理などがこの層に含まれます。この層は、表示方法やデータの保存方法には依存せず、純粋にビジネスルールだけを扱います。

データアクセス層（リポジトリ層）

データベースとのやり取りを担当する層です。データの保存、取得、更新、削除といった操作を実装します。SQLクエリの実行や、ORMを使ったデータ操作がこの層で行われます。この層により、ビジネスロジック層はデータベースの詳細を知る必要がなくなります。

3. プレゼンテーション層の実装例

それでは、実際のGo言語のコードで各層を実装してみましょう。まずはプレゼンテーション層からです。ここではユーザー情報を取得するHTTPハンドラーを実装します。


package handler

import (
    "encoding/json"
    "net/http"
    "strconv"
    "myapp/service"
)

type UserHandler struct {
    userService *service.UserService
}

func NewUserHandler(userService *service.UserService) *UserHandler {
    return &UserHandler{userService: userService}
}

func (h *UserHandler) GetUser(w http.ResponseWriter, r *http.Request) {
    idStr := r.URL.Query().Get("id")
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "無効なIDです", http.StatusBadRequest)
        return
    }
    
    user, err := h.userService.GetUserByID(id)
    if err != nil {
        http.Error(w, "ユーザーが見つかりません", http.StatusNotFound)
        return
    }
    
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(user)
}

このコードでは、UserHandlerがプレゼンテーション層の役割を果たしています。HTTPリクエストを受け取り、パラメータを検証し、ビジネスロジック層のUserServiceに処理を委譲しています。そして、結果をJSON形式でレスポンスとして返します。この層は、HTTPの詳細だけを扱い、ビジネスロジックやデータベースの詳細は知りません。

4. ビジネスロジック層の実装例

次に、ビジネスロジック層を実装します。ここでは、ユーザーに関するビジネスルールを実装します。


package service

import (
    "errors"
    "myapp/model"
    "myapp/repository"
)

type UserService struct {
    userRepo *repository.UserRepository
}

func NewUserService(userRepo *repository.UserRepository) *UserService {
    return &UserService{userRepo: userRepo}
}

func (s *UserService) GetUserByID(id int) (*model.User, error) {
    if id <= 0 {
        return nil, errors.New("IDは正の整数である必要があります")
    }
    
    return s.userRepo.FindByID(id)
}

func (s *UserService) CreateUser(name, email string) (*model.User, error) {
    if name == "" || email == "" {
        return nil, errors.New("名前とメールアドレスは必須です")
    }
    
    exists, err := s.userRepo.ExistsByEmail(email)
    if err != nil {
        return nil, err
    }
    if exists {
        return nil, errors.New("このメールアドレスは既に登録されています")
    }
    
    user := &model.User{
        Name:  name,
        Email: email,
    }
    
    return s.userRepo.Save(user)
}

このコードでは、UserServiceがビジネスロジック層の役割を果たしています。ユーザーIDの検証、メールアドレスの重複チェックなど、アプリケーション固有のルールをここで実装します。データベースへのアクセスは、UserRepositoryに委譲しています。この層は、HTTPの詳細やデータベースのSQL文を知る必要がありません。

5. データアクセス層の実装例

最後に、データアクセス層を実装します。ここでは、実際にデータベースとやり取りするコードを書きます。


package repository

import (
    "database/sql"
    "myapp/model"
)

type UserRepository struct {
    db *sql.DB
}

func NewUserRepository(db *sql.DB) *UserRepository {
    return &UserRepository{db: db}
}

func (r *UserRepository) FindByID(id int) (*model.User, error) {
    query := "SELECT id, name, email FROM users WHERE id = ?"
    
    user := &model.User{}
    err := r.db.QueryRow(query, id).Scan(&user.ID, &user.Name, &user.Email)
    if err != nil {
        return nil, err
    }
    
    return user, nil
}

func (r *UserRepository) ExistsByEmail(email string) (bool, error) {
    query := "SELECT COUNT(*) FROM users WHERE email = ?"
    
    var count int
    err := r.db.QueryRow(query, email).Scan(&count)
    if err != nil {
        return false, err
    }
    
    return count > 0, nil
}

func (r *UserRepository) Save(user *model.User) (*model.User, error) {
    query := "INSERT INTO users (name, email) VALUES (?, ?)"
    
    result, err := r.db.Exec(query, user.Name, user.Email)
    if err != nil {
        return nil, err
    }
    
    id, err := result.LastInsertId()
    if err != nil {
        return nil, err
    }
    
    user.ID = int(id)
    return user, nil
}

このコードでは、UserRepositoryがデータアクセス層の役割を果たしています。SQL文を使ってデータベースからデータを取得したり、保存したりします。この層は、データベースの詳細だけを扱い、ビジネスルールやHTTPの処理は知りません。もしデータベースをMySQLからPostgreSQLに変更したい場合、この層だけを修正すれば対応できます。

6. モデル（エンティティ）の定義

レイヤードアーキテクチャでは、各層で共通して使用するデータ構造を定義します。これをモデルまたはエンティティと呼びます。


package model

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

type Product struct {
    ID          int     `json:"id"`
    Name        string  `json:"name"`
    Price       float64 `json:"price"`
    Stock       int     `json:"stock"`
    Description string  `json:"description"`
}

このコードでは、UserとProductという2つのモデルを定義しています。これらの構造体は、全ての層で共通して使用されます。JSONタグを付けることで、JSON形式への変換が簡単になります。モデルは純粋なデータ構造であり、特定の層に依存しません。

7. 依存関係のルール

レイヤードアーキテクチャで最も重要なルールは、依存関係の方向です。各層は、自分より下の層にのみ依存し、上の層のことは知ってはいけません。

依存の方向

プレゼンテーション層は、ビジネスロジック層に依存します。ビジネスロジック層は、データアクセス層に依存します。しかし、データアクセス層は、ビジネスロジック層やプレゼンテーション層のことを知りません。この一方向の依存関係により、下の層を変更しても上の層への影響を最小限に抑えられます。

循環依存の禁止

プレゼンテーション層がビジネスロジック層を使い、ビジネスロジック層がプレゼンテーション層を使う、といった循環依存は絶対に避けなければなりません。循環依存があると、コードの変更が困難になり、テストもしにくくなります。

層の独立性

各層は独立して動作できるように設計します。これにより、層ごとにユニットテストを書くことができ、品質を保ちやすくなります。例えば、ビジネスロジック層のテストでは、実際のデータベースを使わずに、モックのリポジトリを使ってテストできます。

8. レイヤードアーキテクチャのディレクトリ構成

Go言語でレイヤードアーキテクチャを実装する際の、推奨されるディレクトリ構成を見てみましょう。


myapp/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── handler/
│   │   ├── user_handler.go
│   │   └── product_handler.go
│   ├── service/
│   │   ├── user_service.go
│   │   └── product_service.go
│   ├── repository/
│   │   ├── user_repository.go
│   │   └── product_repository.go
│   └── model/
│       ├── user.go
│       └── product.go
├── pkg/
│   └── database/
│       └── connection.go
└── go.mod

この構成では、handlerディレクトリがプレゼンテーション層、serviceディレクトリがビジネスロジック層、repositoryディレクトリがデータアクセス層に対応しています。modelディレクトリには、全ての層で共通して使用するデータ構造を配置します。cmdディレクトリには、アプリケーションを起動するためのmain.goファイルを配置します。

9. 各層の初期化とメイン関数

レイヤードアーキテクチャでは、各層のオブジェクトを適切に初期化し、依存関係を注入する必要があります。main関数での初期化方法を見てみましょう。


package main

import (
    "database/sql"
    "log"
    "net/http"
    "myapp/handler"
    "myapp/repository"
    "myapp/service"
    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, err := sql.Open("mysql", "user:password@tcp(localhost:3306)/mydb")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()
    
    userRepo := repository.NewUserRepository(db)
    userService := service.NewUserService(userRepo)
    userHandler := handler.NewUserHandler(userService)
    
    http.HandleFunc("/user", userHandler.GetUser)
    
    log.Println("サーバーを起動します: http://localhost:8080")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal(err)
    }
}

このコードでは、下の層から順番にオブジェクトを作成しています。まずデータベース接続を確立し、それを使ってUserRepositoryを作成します。次に、そのリポジトリを使ってUserServiceを作成し、最後にそのサービスを使ってUserHandlerを作成します。このように、各層に必要な依存物を外部から注入することで、層間の結合度を低く保つことができます。

Go言語を基礎からスッキリ学びたい人や、文法だけでなく「実用的な使い方」まで押さえたい人には、定番の入門書がこちらです。

基礎からわかるGo言語をAmazonで見る

※ Amazon広告リンク

10. レイヤードアーキテクチャのメリットと注意点

レイヤードアーキテクチャには、多くのメリットがある一方で、いくつか注意すべき点もあります。

メリット

保守性の向上：各層の責任が明確なため、コードの理解や修正が容易になります。
テストのしやすさ：各層を独立してテストできるため、品質を保ちやすくなります。
再利用性：ビジネスロジック層やデータアクセス層は、異なるプレゼンテーション層から再利用できます。
技術の変更が容易：データベースやWebフレームワークの変更が、他の層に影響を与えにくくなります。

注意点

小規模プロジェクトには過剰：数百行程度の小さなプログラムには、この設計は複雑すぎる場合があります。
パフォーマンス：層が増えることで、メソッド呼び出しが増え、わずかにパフォーマンスが低下する可能性があります。
学習コスト：初心者にとっては、層の概念や依存関係のルールを理解するのに時間がかかります。

レイヤードアーキテクチャは、中規模から大規模のアプリケーション開発で特に威力を発揮します。最初は層を分けることが面倒に感じるかもしれませんが、プロジェクトが成長するにつれて、その価値を実感できるでしょう。Go言語のシンプルな思想と、レイヤードアーキテクチャの明確な設計原則は相性が良く、保守性の高いアプリケーションを構築できます。