モジュラモノリス徹底解剖 〜実践者から学ぶ Lunch LT〜 に参加しました。オンライン参加。簡単に所感をまとめます。
所感
モジュラーモノリス検討中ですっていうひとが思ってたより多かった気がする。Go の Workspace mode はモジュラーモノリスを実現しやすい仕組みなんだろうか。言語レベルでそういうのサポートしているのよさそう。
モジュールの依存関係はコンテキストマップを踏襲する。あと、DB を分割しておくとマイクロサービスにも移行しやすい。なるほど。
マイクロサービスが負債になるっていうのは心に留めておきたい😇
以下、メモから抜粋。
非モジュラーモノリスからモジュラーモノリスへのステップ
- チーム分割しても生産性を維持したい
- 分散トランザクション
- モジュラーモノリス構成
- BFF
- モジュール間は循環依存しないように
- モジュール間の RDB 分離
- 外部キー張ってたりするので難しい
- モジュール間のトランザクション
- 基本的にはないように
- 仕様見直し
- モジュール粒度
- 最初はなるべく小さく
- 小さいモジュールをまとめてモジュール化
RDRAとDDDでGoのモジュラーモノリスアプリを設計してみた話
- RDRA
- 戦略的DDD
- コンテキストマップごとの設計資料
- Workspace mode (Go)
- モジュール間の依存解決
- コンテキストマップと同じ粒度で Go Module を作成する
- マイクロサービス
- モジュールを別リポジトリに切り出す
- 新規なのでDB分割はやりやすかった
TypeScript・モジュラーモノリスによる型安全なWebサービス開発
- 複雑なサービスをシンプルなモジュールを組み合わせて作り上げる
- 垂直分割=ドメインごとに分割
- 水平分割=レイヤごとに分割
- コアロジックを外に抽出
- 凝集度が高い
- FE/BEにロジックが分散しないように
- Turborepo
- 関数を export する
- モジュール間は関数呼び出し
- ドメインロジックを書くべきところに書く
- ビルド, Lint はパフォーマンスわるい
- 初期構築の難易度が高い
- モノリポと相性いい
マイクロサービスではなくモジュラモノリスを採用した理由
- 既存システムの技術負債
- 新機能を別システムで作る
- 既存システムを少しずつ移行
- マイクロサービス
- 整合性担保が難しい
- マイクロサービスが負債になる
- モノリス
- 内部品質を保つには設計スキルが必要
- 将来的にマイクロサービスに移行しづらい
- モジュラーモノリス
- モジュール境界はサービス境界に比べて戻しやすい
- サービス境界を探る
