Go言語でモジュラーモノリスのアプリ開発をする際のノウハウを公開

はじめに

こんにちは、imamoto です。
今年もプロ野球が開幕し、すっかり春だなぁと感じる今日この頃です。

さて今回は、Go言語でのWebアプリ開発をした際のチーム内のノウハウを、GitHub上で公開してみた話を書いていきたいと思います。

公開したGitHub リポジトリの紹介

私はSRE課に所属しているのですが、SRE課ではGo言語でWebアプリを開発することが多いです。
独立した機能を持った複数のGo Moduleを、1つのモノリスなアプリケーションとしてデプロイする、
いわゆる モジュラーモノリス という設計でのアプリ開発にもチャレンジしているのですが、
その開発中にチームとして蓄積した実装ルールやノウハウのうち、汎用化できそうな部分をまとめて、
以下のGitHub リポジトリ上に公開したので紹介させてください。

github.com

この記事では、以下の3点について説明していきたいと思います。

資料の構成について
モジュラーモノリスで実装した背景
ノウハウ公開に至った経緯

資料の構成について

まとめた内容は、以下のGitHub上のREADMEファイルを出発点にして学習できるようになっています。

github.com

前提として、Webフレームワークはgin-gonic/gin、ORMはGORM、DI ツールはgoogle/wireを使用しています。

また、3.推奨する学習順序の項にも記載してありますが、資料は以下の9つの領域で構成されています。
(2023年4月時点での内容であり、予告なく構成を変更する可能性があります)

Basics: DDD の基本説明、ディレクトリ構成等、当資料を参照するにあたって認識いただきたい前提知識を記載しています。
Multi Module Project: モジュラーモノリス構成のアプリに対して、Go の Workspace 機能を用いて名前解決する方法を記載しています。＜3. Layered Architecture: 単一の Go Module はレイヤードアーキテクチャの構成を取っています。各レイヤーの説明と基本的な実装方法を記載しています。
Dependency Injection: 各レイヤーをまたいだオブジェクトのファクトリ関数をgoogle/wireで生成する手法を記載しています。
Transaction: DB トランザクションの制御の実装方法を記載しています。
Routing And Middleware: Web フレームワーク Gin を用いたルーティングの実装方法を記載しています。
Row Level Security: PostgreSQL の Row Level Security を、ORM の Gorm を用いて実装する方法を記載しています。
Goroutine Job: Goroutine を使ったバッチ処理の実装方法を記載しています。
Unit Test: 単体テストの基本的な記述方法を記載しています。

DDD、レイヤードアーキテクチャ、モジュラーモノリス等の全体的な設計に関わるトピックだけでなく、
DBトランザクション、RLS、DI等の具体的な実装に関わるトピックも含まれています。
多くの方に少しでもお役に立てていただくことができますと幸いです。

モジュラーモノリスで実装した背景

今回まとめたノウハウはモジュラーモノリスのアプリケーションであることが前提となっていますが、
設計としてモジュラーモノリスを選択した背景は以下の3点に集約されます。

業務ロジックの複雑度
単一チームでの開発のためMSA化の必要性が低い
Go Moduleを使えばシンプルにモジュラーモノリス構成を実現可能

実現したい業務ロジックがかなり複雑なアプリを開発する必要があったので、
単純なモノリスのアプリケーションにすると複雑度が高くなりすぎるというリスクが開発当初からありました。

そのため、コンテキストマップの設計をすることで適切なモジュール分割を実施し、
実際のアプリケーションの構成と一致させることを目指しました。

ただ、単一チームでの開発で複数のマイクロサービスに分けて開発するとメンテ工数だけ増加しメリットがあまり無い点、
Go言語のGo Moduleを連携させればコンテキストマップの構成とアプリの構成を一致させることができる点を踏まえて、
モジュラーモノリスという形を取ることにしました。

ノウハウ公開に至った経緯

私が所属するSRE課は、私を含めメンバー全員がほぼGo言語の開発経験がないところからのスタートだったので、
有識者がみんなを引っ張っていくスタイルを取ることができませんでした。
そのため、学習・試行錯誤・軌道修正をを繰り返しながらより良い実装の仕方を固めていくという形で開発を進めました。

一方、設計や実装の背景と、それらに付随する用語を理解する必要がある領域が多い構成になっているにも関わらず、
それらのドキュメンテーションが追い付いていなかったため、
途中から参画してくるメンバーに対するオンボーディングにおいては口頭で説明せざるを得ない状況になっており、
既存メンバーと新規メンバーの間で、重要な概念に対する理解度に開きが生まれてしまうリスクが生まれてしまっていました。

そのリスクを解消するべく、必要なノウハウを汎用的にまとめてチームで共有することにしました。
また、自分たちの試行錯誤の結果を一般に公開することで、他のエンジニアの助けになれば良いなという思いと同時に、より良い実装方針のフィードバックも外部からいただけるかもしれないという思いもあり、今回はGitHub上で一般公開するという結論に至りました。