Content last updated 2026-06-15

モジュラーモノリス ADR 001: アプリケーションドメインのモジュール化

コンテキスト

コードベースをモジュール化する前に、まずどのように分割するかを定義する必要がありました。

最初に、アプリケーションアダプター（Web コントローラーとビュー、REST/GraphQL エンドポイント）をモジュール化の初期スコープ外に置きながら、アプリケーションドメイン（バックエンドビジネスロジック）に焦点を当てることから始めます。

その理由は以下のとおりです:

アプリケーションアダプター内のコードは、必ずしも特定のドメインに対応しているわけではありません。例えば: プロジェクト設定エンドポイントやマージリクエストページには、多くのドメインへの参照が含まれます。
メモリを節約するために、異なるプロファイルを使用して SaaS アーキテクチャ向けに別々の Rails ノードを実行する必要がありました。例えば: SaaS では、Rails アプリケーション全体をロードすることなく、より多くの Sidekiq ノードを起動できるようにしたいと考えていました。前提として、Sidekiq の実行には ActionCable、REST エンドポイント、GraphQL ミューテーション、Rails ビューは不要です。必要なのはアプリケーションドメインとインフラストラクチャコードだけです。 Cells の導入後もこれは依然として当てはまるかもしれませんが、この前提を再評価する必要があります。
スコープと作業量を小さく保つ。ドメインコードのみに取り組む方が、アプリケーションアダプターをどのように分解するかとそのすべてのエッジケースの複雑さよりも理解しやすいです。

アプリケーションアダプターをスコープ外にする決定は最終的なものではなく、後に延期することにしました。

最後に、技術的な懸念事項を含むインフラストラクチャコード（通常は lib/）は、すべてのドメインモジュールが機能するために依存する共通の「プラットフォーム」レイヤーの一部となります。

「プラットフォーム」レイヤーは、gem として抽出された独立したライブラリに分解できます。

ビジネスロジックのモジュール化に焦点を当て、エンジニア向けのルールとガイドラインを定義します。モジュール全体に同じパターンセットを適用できます。

アプリケーションアダプターをモジュール化の取り組みに含めることも検討しましたが、アダプターのモジュール化はルートのようなユーザー向けの依存関係を保持する必要があるため、より繊細であることに気づきました。