Go_MYクリーンアーキテクチャ

date
Aug 25, 2023
slug
cleanArchitecture
status
Published
tags
cleanArchitecture
summary
依存関係を下層から上層への一方向にしている点です
type
Post

クリーンアーキテクチャ

「クリーンアーキテクチャ」はRobert C. Martin (Uncle Bob)によって提唱されたアーキテクチャの設計原則の一つで、ソフトウェアがビジネスロジックに集中し、外部の詳細(フレームワーク、データベース、インターフェースなど)から独立していることを目的としています。Go (Golang) においても、このアーキテクチャ原則を採用したプロジェクトが数多く存在します。
以下は、Golangのクリーンアーキテクチャを採用したときのフォルダー構造の例です:

1. 例

ポイントは、各層が明確に分離されていて、依存関係が内側 (domain) から外側 (infrastructure, app) へと一方向になっていることを確認することです。
/root |-- /app |   |-- /handler       # リクエストを受け取り、レスポンスを返すためのハンドラ(Controllerの役割) |   |-- /middleware     # Middleware関連 (認証、ロギングなど) | |-- /domain |   |-- /entity         # ドメインモデル (Databaseのテーブルやオブジェクトの定義) |   |-- /repository     # データの保存や取得に関するインターフェース |   |-- /service       # ビジネスロジックやドメインロジックを実装 |   |-- /usecase       # アプリケーションのユースケースを表現 | |-- /infrastructure |   |-- /db             # データベース接続、マイグレーション、ORMなど |   |-- /logger         # ロギングの実装 |   |-- /repository     # repositoryインターフェースの実際の実装 (例: DBへの保存や取得の処理) | |-- /cmd               # アプリケーションのエントリーポイントやCLIツール | |-- go.mod             # 依存関係の管理 |-- go.sum             # 依存関係のチェックサム |-- main.go             # アプリケーションの起動ポイント
この構造は一例に過ぎません。実際のプロジェクトやチームのニーズに合わせて、必要に応じて調整を行うことが大切です。

2.例

クリーンアーキテクチャの主な目的は、外部の詳細から独立したビジネスロジックの層を持つことなので、その原則に従って構造を適応・変更することが大切です。
/project-name |--/cmd | |--/appname | | |--main.go | |--/pkg | |--/usecase | | |--/user | | | |--usecase.go | | | |--usecase_test.go | | | |--/repository | | |--/user | | | |--memory.go | | | |--mysql.go | | | |--repository.go | | | |--/entity | | |--user.go | |--/internal | |--/handler | | |--/http | | | |--user_handler.go | | |--/middleware | | |--auth.go | |--/config | |--config.go | |--/migration | |--001_initial_setup.sql | |--/scripts | |--deploy.sh | |--go.mod |--go.sum |--README.md
この構造の説明:
  1. cmd - アプリケーションのエントリーポイント。main関数がここに配置される。
  1. pkg - 主要なビジネスロジックやコアロジックが配置される。
      • usecase - アプリケーションのユースケースやビジネスロジックを表現する。
      • repository - データの永続化やデータアクセスメソッドを持つインターフェースと、それを実装する具体的なリポジトリ。
      • entity - ドメインオブジェクトやエンティティの定義。
  1. internal - アプリケーションの内部の実装。
      • handler - HTTPリクエストハンドラや、その他のインターフェースのハンドラ。
      • middleware - ミドルウェアの定義や実装。
  1. config - アプリケーションの設定や環境変数の管理。
  1. migration - データベースのマイグレーションスクリプト。
  1. scripts - デプロイやビルドを助けるスクリプト。

3.例:

クリーンアーキテクチャの重要な要点は、内部のレイヤーが外部のレイヤーに依存しないようにすることです。
project-root/ ├── cmd/ │   └── appname/ │       └── main.go     # アプリケーションのエントリーポイント ├── api/               # API定義やミドルウェア │   ├── handler/ │   ├── middleware/ │   └── response/ ├── domain/             # ドメインロジックやエンティティの定義 │   ├── entity/ │   └── service/ ├── usecase/           # アプリケーションのユースケースを表現するロジック ├── repository/         # データへのアクセス方法を定義 (例: DB, 他のサービス) ├── delivery/           # アプリケーションのインターフェース部分 (例: HTTP, gRPC) │   ├── http/ │   └── grpc/ ├── pkg/               # 共用のヘルパー関数やライブラリ └── infrastructure/     # データベースの接続、ログ、外部サービスとの通信などのインフラ関連のコード
この構造のいくつかのポイント:
  • cmd/: アプリケーションの実際のエントリーポイント。main.go では依存性の注入やアプリケーションの起動処理を行う。
  • domain/: アプリケーションの中核をなすドメインロジックやエンティティをここに配置する。
  • usecase/: ビジネスロジックを表現する部分。
  • repository/: 永続化のためのインターフェースを定義。具体的な実装は infrastructure/ にある。
  • delivery/: アプリケーションがどのようにデリバリーされるかを定義 (例: HTTP API, gRPC, CLI など)。
  • pkg/: アプリケーション全体で使用するヘルパーや共通の関数。
  • infrastructure/: インフラストラクチャ関連の具体的な実装を配置。
上のフォルダ構造では、domain は中心にあり、他のすべての部分が domain に依存しますが、逆はありません。
記事に関する疑問があればお気軽にご連絡ください。