Practical Guide To Apply Clean Architecture In Go

📄 Summarized by Claude Sonnet 4.5

2024年以降に公開（具体的な日付は記載なし）

どんなもの？

サイバーエージェントハノイDevCenterのバックエンドエンジニアインターンが、Go言語でClean Architectureを実践的に適用した経験をまとめた技術ガイド

大規模モノレポ環境で複数のマイクロサービス間の一貫した構造を定義し、go-arch-lintツールを活用してアーキテクチャの境界を自動的に検証する手法を紹介

Robert C. Martinが提唱したClean Architectureの原則を厳格すぎず実用的に適用し、コードの保守性とテスト容易性を向上させる

先行研究と比べてどこがすごい？

既存のClean Architecture理論をGo言語の特性に合わせて実用的にカスタマイズした点

モノレポ環境での適用に特化し、複数サービスの構造一貫性を維持する具体的な実装を提示

go-arch-lintとGitHub Actions、reviewdog、yqを組み合わせた自動化パイプラインにより、変更されたサービスのみを動的に検証する効率的な仕組みを構築

理論だけでなく実際のYAML設定ファイル、シェルスクリプト、Makefile、CI設定まで含む実践的なコード例を提供

技術や手法のキモはどこ？

4層のレイヤー構造：entity（ドメインモデル）、usecase（アプリケーションロジック）、handler（インターフェース層）、repository（インフラ層）に明確に分離

依存関係の逆転：内側の層は外側の層に依存せず、usecaseがrepositoryのインターフェースを定義し、実装は外側の層で行う

go-arch-lintの設定でcomponentsとdepsを定義し、各層の依存許可を厳密に制御

モノレポ対応：変更検知スクリプトでgit diffにより変更されたサービスのみを対象に、yqでworkdirを動的に書き換えて検証

GitHub Actionsでreviewdogを使い、PR上に違反を直接コメントとして表示

どうやって有効だと検証した？

実際のABEMAチームの大規模モノレポ環境で適用し、複数のマイクロサービス間で一貫した構造を実現

CI/CDパイプラインに統合し、PR段階でアーキテクチャ違反を自動検出できることを確認

新規開発者のオンボーディング時間の短縮と、コードレビューの効率化を実現

entityやusecase層が外部フレームワークに依存しないため、単体テストが容易になることを実証

議論はある？

go-arch-lintの公式Dockerイメージに問題があるため、現状はgolangベースイメージを使用する必要がある

ignoreNotFoundComponentsを有効にすると構造の一貫性が低下するリスクがあり、厳格さとのバランスが課題

Clean Architectureの原則を「厳格すぎず実用的に」適用する範囲の判断は、チームやプロジェクトの特性により調整が必要

モノレポ環境では各サービスに対して個別の設定が不要な反面、共通ルールの変更時に全サービスへの影響を慎重に検討する必要がある

アーキテクチャ規約がチーム合意であり、CIで検証することが重要だが、過度に厳格なルールは開発速度を低下させる可能性もある