DokumentePreiseBlog
Kontaktieren Sie uns
AnmeldenKOSTENLOS anmelden
Back to Tech Articles

Go Webアプリケーションの保守性と適応性のためのアーキテクチャ

Okt. 15, 2025
# Misc

Ethan Miller

Product Engineer · Leapcell

Dieser Beitrag ist auch in English, 한국어 und Deutsch verfügbar
Cover of "Go Webアプリケーションの保守性と適応性のためのアーキテクチャ"

はじめに

堅牢でスケーラブルなWebアプリケーションを構築するには、機能的なコードを書くだけでは不十分です。プロジェクトが複雑化するにつれて、ビジネスロジックと基盤となるフレームワークとの間の緊密な結合は、保守性、テスト容易性、および将来の進化にとって重大な障害となることがよくあります。この緊密な結合により、新しい要件への適応やフレームワークの切り替えが困難な作業となり、通常は広範なリファクタリングが必要になります。この記事では、Go Webプロジェクトでクリーンアーキテクチャを実践し、コアビジネスロジックを外部依存関係から分離することを目指します。これにより、変更に強く、テストしやすく、最終的により持続可能なアプリケーションを構築することを目指します。クリーンアーキテクチャの原則を掘り下げ、Goでの実践的な適用方法を示し、関心の明確な分離を達成する方法を説明します。

コアコンセプトの理解

実装の詳細に入る前に、クリーンアーキテクチャの中心となる主要なコンセプトについて共通の理解を深めましょう。

  • クリーンアーキテクチャ: Robert C. Martin（Uncle Bob）によって提唱されたクリーンアーキテクチャは、同心円状のレイヤーを提唱するアーキテクチャ哲学であり、最も内側のレイヤーはコアビジネスロジックを表し、最も外側のレイヤーはデータベース、UI、フレームワークなどの外部の懸念事項を処理します。基本的な原則は依存関係のルールです。「依存関係は内向きにのみ指すことができます。」これは、内側のレイヤーが外側のレイヤーに依存してはならないことを意味します。

  • エンティティ: これらはエンタープライズ全体のビジネスルールです。それらは最も一般的で高レベルなルールをカプセル化しており、特定のアプリケーションの影響を受けません。Goでは、これらはコアドメインオブジェクトを表す単純な構造体であることがよくあります。

  • ユースケース（インターアクター）: これらはアプリケーション固有のビジネスルールを含みます。それらはエンティティへのおよびからのデータの流れを調整し、アプリケーションの動作を定義します。ユースケースはUI、データベース、またはその他の外部の懸念事項を認識しません。それらは入力と出力を扱い、アプリケーションの特定のアクションまたは機能を表します。

  • インターフェイスアダプター: このレイヤーは、ユースケースと外部世界の間に位置します。ユースケースとエンティティに最も便利な形式のデータを、データベースやWebフレームワークなどの外部エージェントに最も便利な形式に適合させます。これには、コントローラー、プレゼンター、ゲートウェイが含まれます。

  • フレームワークとドライバー: これは最も外側のレイヤーであり、フレームワーク（GinやEchoなど）、データベース、Webサーバー、その他の外部ツールで構成されます。このレイヤーは実装の詳細です。コアビジネスロジック（エンティティとユースケース）は、その存在を意識しないようにする必要があります。

このレイヤー化されたアプローチ（しばしば同心円として視覚化される）の美しさは、最も外側のレイヤーでの変更が内側のレイヤーに最小限の影響しか与えないことで、柔軟性とテスト容易性を最大化することです。

Go Webプロジェクトでのクリーンアーキテクチャの実践

簡単な「To-Doリスト」アプリケーションを例にとり、これらのコンセプトを説明しましょう。ここでは、コアとなる「新しいTo-Doアイテムを作成する」機能に焦点を当てます。

プロジェクト構造

クリーンアーキテクチャに従った典型的なプロジェクト構造は次のようになります。

├── cmd/
│   └── main.go
├── internal/
│   ├── adapters/
│   │   ├── http/
│   │   │   └── todoHandler.go
│   │   └── repository/
│   │       └── todoRepository.go
│   ├── application/
│   │   └── usecase/
│   │       └── createTodo.go
│   └── domain/
│       ├── entity/
│       │   └── todo.go
│       └── repository/
│           └── todo.go // リポジトリのインターフェイス
└── pkg/
    └── utils/

1. ドメインレイヤー：エンティティとリポジトリインターフェイス

domainレイヤーは、コアビジネスオブジェクトとそれらを操作するための契約を定義します。

internal/domain/entity/todo.go:

package entity

import "time"

// ToDoは単一のto-doアイテムを表します。
type ToDo struct {
	ID        string    `json:"id"`
	Title     string    `json:"title"`
	Completed bool      `json:"completed"`
	CreatedAt time.Time `json:"createdAt"`
}

// NewToDoはデフォルト値を持つ新しいToDoアイテムを作成します。
func NewToDo(id, title string) *ToDo {
	return &ToDo{
		ID:        id,
		Title:     title,
		Completed: false,
		CreatedAt: time.Now(),
	}
}

internal/domain/repository/todo.go:

package repository

import "context"
import "your-app/internal/domain/entity" // 明確さのために絶対パスを使用

// ToDoRepositoryはToDoストレージとの対話のためのインターフェイスを定義します。
type ToDoRepository interface {
	Save(ctx context.Context, todo *entity.ToDo) error
	FindByID(ctx context.Context, id string) (*entity.ToDo, error)
	// FindAll、Update、Deleteなどの他のメソッドを追加
}

domainレイヤーは特定のデータベース実装（例：PostgreSQL、MongoDB）を一切知らないことに注意してください。永続化のための契約のみを定義します。

2. アプリケーションレイヤー：ユースケース

applicationレイヤーには、アプリケーション固有のビジネスロジックが含まれています。リポジトリインターフェイスを使用してドメインエンティティを調整します。

internal/application/usecase/createTodo.go:

package usecase

import (
	"context"
	"your-app/internal/domain/entity"
	"your-app/internal/domain/repository"

	"github.com/google/uuid" // 一意なIDを生成するため
)

// CreateToDoInputはToDo作成のための入力データを定義します。
type CreateToDoInput struct {
	Title string `json:"title"`
}

// CreateToDoOutputはToDo作成後の出力データを定義します。
type CreateToDoOutput struct {
	ID    string `json:"id"`
	Title string `json:"title"`
}

// CreateToDoは新しいToDoアイテムを作成するためのユースケースを表します。
type CreateToDo struct {
	repo repository.ToDoRepository
}

// NewCreateToDoは新しいCreateToDoユースケースを作成します。
func NewCreateToDo(repo repository.ToDoRepository) *CreateToDo {
	return &CreateToDo{repo: repo}
}

// ExecuteはToDoを作成するためのロジックを実行します。
func (uc *CreateToDo) Execute(ctx context.Context, input CreateToDoInput) (*CreateToDoOutput, error) {
	// ビジネスルール：タイトルは空にできません
	if input.Title == "" {
		return nil, entity.ErrInvalidToDoTitle // entity.ErrInvalidToDoTitleが定義されていると仮定
	}

	todoID := uuid.New().String()
	todo := entity.NewToDo(todoID, input.Title)

	err := uc.repo.Save(ctx, todo)
	if err != nil {
		return nil, err
	}

	return &CreateToDoOutput{
		ID:    todo.ID,
		Title: todo.Title,
	},
 nil
}

CreateToDoユースケースは、Webフレームワークや特定のデータベースとは完全に独立しています。ToDoRepositoryインターフェイスとToDoエンティティのみとやり取りします。

3. インターフェイスアダプタレイヤー：リポジトリ実装とHTTPハンドラー

このレイヤーは、アプリケーションレイヤーを外部世界に接続します。

internal/adapters/repository/todoRepository.go（単純化のためインメモリ使用例）：

package repository

import (
	"context"
	"fmt"
	"sync"
	"your-app/internal/domain/entity"
	"your-app/internal/domain/repository"
)

// InMemoryToDoRepositoryはToDoRepositoryインターフェイスを実装します。
type InMemoryToDoRepository struct {
	mu    sync.RWMutex
	store map[string]*entity.ToDo
}

// NewInMemoryToDoRepositoryは新しいインメモリリポジトリを作成します。
func NewInMemoryToDoRepository() *InMemoryToDoRepository {
	return &InMemoryToDoRepository{
		store: make(map[string]*entity.ToDo),
	}
}

// SaveはToDoアイテムをメモリに保存します。
func (r *InMemoryToDoRepository) Save(ctx context.Context, todo *entity.ToDo) error {
	r.mu.Lock()
	defer r.mu.Unlock()
	r.store[todo.ID] = todo
	return nil
}

// FindByIDはメモリからToDoアイテムを取得します。
func (r *InMemoryToDoRepository) FindByID(ctx context.Context, id string) (*entity.ToDo, error) {
	r.mu.RLock()
	defer r.mu.RUnlock()
	todo, ok := r.store[id]
	if !ok {
		return nil, fmt.Errorf("todo with ID %s not found", id) // ドメイン固有のエラーを検討
	}
	return todo, nil
}

このリポジトリ実装はrepository.ToDoRepositoryインターフェイスを満たします。applicationレイヤーやdomainレイヤーに触れることなく、PostgreSQLやMongoDBの実装に簡単に切り替えることができます。

internal/adapters/http/todoHandler.go（Gin/Echoに似た仮説のHTTPフレームワークを使用）：

package http

import (
	"encoding/json"
	"net/http"
	"your-app/internal/application/usecase"
	"your-app/internal/domain/entity" // エラー処理例のため
)

// ToDoHandlerはToDoアイテムに関連するHTTPリクエストを処理します。
type ToDoHandler struct {
	createToDoUseCase *usecase.CreateToDo
	// その他のユースケース
}

// NewToDoHandlerは新しいToDoHandlerを作成します。
func NewToDoHandler(createToDoUC *usecase.CreateToDo) *ToDoHandler {
	return &ToDoHandler{
		createToDoUseCase: createToDoUC,
	}
}

// CreateToDoは新しいToDoを作成するためのHTTP POSTリクエストを処理します。
func (h *ToDoHandler) CreateToDo(w http.ResponseWriter, r *http.Request) {
	var req usecase.CreateToDoInput
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}

	output, err := h.createToDoUseCase.Execute(r.Context(), req)
	if err != nil {
		switch err {
		case entity.ErrInvalidToDoTitle: // ドメイン固有のエラーを処理する例
			http.Error(w, err.Error(), http.StatusBadRequest)
		default:
			http.Error(w, "Failed to create ToDo", http.StatusInternalServerError)
		}
		return
	}

	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(output)
}

このHTTPハンドラーは、Webフレームワーク（ここでは標準のnet/http）に固有のものです。HTTPリクエストをユースケース入力に、ユースケース出力をHTTPレスポンスに変換します。usecase.CreateToDoに依存していますが、その内部実装やToDoの永続化方法については認識していません。

4. フレームワークレイヤー：すべてを配線する

最後に、cmd/main.goが私たちの「メイン」コンポーネントとして機能し、すべてのピースを組み立てます。

cmd/main.go:

package main

import (
	"log"
	"net/http"
	"your-app/internal/adapters/http"
	"your-app/internal/adapters/repository"
	"your-app/internal/application/usecase"
)

func main() {
	// フレームワークとドライバーレイヤー（メインの構成）
	// リポジトリ（データベース）の初期化
	todoRepo := repository.NewInMemoryToDoRepository()

	// ユースケースの初期化
	createToDoUC := usecase.NewCreateToDo(todoRepo)

	// HTTPハンドラーの初期化
	todoHandler := http.NewToDoHandler(createToDoUC)

	// HTTPサーバーの設定
	mux := http.NewServeMux()
	mux.HandleFunc("/todos", todoHandler.CreateToDo)

	log.Println("Server starting on port 8080...")
	if err := http.ListenAndServe(":8080", mux); err != nil {
		log.Fatalf("Server failed to start: %v", err)
	}
}

main.goファイルは、具体的な実装をインスタンス化し、「配線」するところです。main.goはすべての他のレイヤーに依存していますが、内側のレイヤーは独立したままであることに注意してください。

アプリケーションシナリオとメリット

この構造は、いくつかの具体的なメリットをもたらします。

  1. テスト容易性: 各レイヤーは独立してテストできます。Webサーバーを起動したり、実際のデータベースに接続したりすることなく、ToDoRepositoryインターフェイスをモックすることで、ユースケースを単体テストできます。これにより、テストが大幅に高速化され、ビジネスロジックに対する信頼性が向上します。
  2. 保守性: UIの変更（例：RESTからGraphQLへの切り替え）やデータベースの変更（例：PostgreSQLからMongoDBへの切り替え）は、Interface Adaptersレイヤーの変更のみを必要とし、コアのApplicationとDomainレイヤーに影響を与えません。
  3. 柔軟性: アプリケーションはフレームワークに依存しなくなります。新しい画期的なGo Webフレームワークが登場した場合、それに適応させることは、主にHTTPアダプターのリファクタリングであり、コアビジネスロジックではありません。
  4. 明瞭性: 関心の分離により、さまざまな種類のロジックがどこに配置されるかが非常に明確になります。ビジネスルールはdomainとapplicationに、外部インターフェイスはadaptersにあります。

結論

Go Webプロジェクトでクリーンアーキテクチャを実装し、ビジネスロジックをフレームワークの依存関係から厳密に分離することで、本質的にテスト容易性、保守性、適応性の高いアプリケーションが得られます。依存関係のルールに従い、コードをドメイン、アプリケーション、インターフェイスアダプターなどの明確なレイヤーに構造化することにより、ソフトウェア開発の必然的な変更や複雑さに耐えられる堅牢な基盤を作成します。このアーキテクチャ上の規律に投資する初期の労力は、長期的には、アプリケーションが進化する要件や技術的シフトに対して柔軟で回復力があることを保証し、配当となります。

クリーンアーキテクチャは、機能するだけでなく、長持ちするように構築されたGo Webアプリケーションを作成するのに役立ちます。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts