Go言語(gin)を用いたサーバを構築する際に、モジュラモノリス構造を実現するためのフォルダ構成等を試行錯誤した結果を示す。
モジュラモノリス構造は時が来た時にマイクロサービスへ簡単に切り出せるし、素晴らしいアーキテクチャですね(^_^)

こちらにサンプルコードがあるのでそれをベースに..

アーキテクチャ

サーバとしてはモバイルアプリから呼ばれるAPIサーバである。(Viewは存在しない)
今担当してるプロダクトに準拠してユーザ管理、メッセージ送信、歩数ランキング機能を保有しているものとする。

User Model
- ユーザ登録、Tokenによる認証等、よくあるやつ
Message Model
- ユーザ間のメッセージ送信機能
StepRank Model
- ユーザ間で歩数を競う機能を提供
DB
- DBは単一のDBを採用して、スキーマを分けることによりそれぞれのモジュールが専用のDBを保有しているようにしている
- MySQLベースでの考え方だが、スキーマじゃなくてそれぞれ別のDBを採用することも当然可能である
Module API
- Model同士を橋渡しするAPI。ユーザ認証等。どうやって図に書けばいいかわからなかった…
- 将来それぞれのモジュールをマイクロサービスへ分離した際にはAPI(HTTP等)として実現するべき境界線となる

ファイル構成

┣main.go
┣database
┗modules
 ┣module_api.go
 ┣user
 ┃┣ucon
 ┃┃┗user_controller.go
 ┃┣umodel
 ┃┃┣repository_interface.go
 ┃┃┗user_model.go
 ┃┗urepo
 ┃ ┗user_repository.go
 ┣message
 ┃┣mcon
 ┃┃┗message_controller.go
 ┃┣mmodel
 ┃┃┣repository_interface.go
 ┃┃┗message_model.go
 ┃┗mrepo
 ┃ ┗message_repository.go
 ┗steprank
  ┣srcon
  ┃┗steprank_controller.go
  ┣srmodel
  ┣repository_interface.go
  ┃┗steprank_model.go
  ┗srrepo
   ┗steprank_repository.go

main.go
- routeの設定、DB接続、modulesへの依存の注入等を担う
modules
- 今回の要各モジュールが独立して存在している
module_api.go
- モジュール間インターフェース定義箇所
repository_interface.go
- 各ModelとRepositoryの依存を反転させ、テストコードの記載等を簡単にする
- Controllerとの反転まではしてない

main.go等一部を除いて将来各サービスがある程度大きくなったりした場合には最低限の労力で切り出してマイクロサービス化できる構造になっている。