モジュラーモノリスの簡単さ/難しさ

はい、というわけで今回はね。モジュラーモノリスの簡単さ、難しさというタイトルでやっていきたいと思うんですけれども(ユーチューバー風)
実際にモジュラーモノリスに取り組もうとして感じた簡単さ、難しさに関して今日は書いていこうと思います。

モジュラーモノリスの簡単さ

まずは簡単さから書いていきたいと思います

モジュールの分割が用意

はい、モジュラーモノリスは何と言ってももちろん分割するのはとても簡単です
マイクロサービスであれば、一個一個切り出すのに別のデプロイ環境やサーバー、インフラが必要になってきます
一方で、モジュラーモノリスでやればモジュールを切るだけで済むので、作業コストがかなり低いです

デプロイが容易

モジュラーモノリスの場合、マイクロサービスのように別のサービスを作るわけではないので
デプロイはそのままで良いです
つまり、単一のモノリスを扱うという状況は変わりないので、デプロイに関して悩む必要はありません

疎結合な設計にしやすい

モノリスでありながら、モジュールごとに分割していくので、明確な境界を作りやすいのも特徴です
モジュール間は直接的な依存ができず、参照もできません
そのため、意図的に疎結合な状態、独立した状態を作り出すことができます

トライアンドエラーしやすい

マイクロサービスであれば、作った時にデプロイ、リリースをした後
「あ、失敗だった」となった時のコストが高いです。
可逆性、不可逆性の観点で言うと失敗に対してリスクが低いと言えます。

モジュラーモノリスの難しさ

ここまではモジュラーモノリスの簡単さについて書いてきました
続いてモジュラーモノリスの難しさについて書いていきます

分割が簡単すぎる

モジュラーモノリスは分割が簡単すぎます
思いたったら分割できてしまいます

機能単位で分割してしまう

分割が容易なため、「とりあえずこの単位で分割してみよう」というアプローチになりがちです。
それを開発の中でやるため、その開発の粒度に依存し、モジュールを分割しようとしてしまいます
そうすると、実際はドメインの単位。つまり、マイクロサービスに切るような単位でモジュール分割をするべきところを、単に小さな機能の単位での分割を行ってしまうことが多くあります。
そのため、モジュール分割は簡単な分、慎重になる必要があります。

同じ型を使いまわしたい欲求に駆られる

モジュラーモノリスの場合モジュールごとに、隣り合って似たような型があるように見えます。
この「すぐ近くに見える」というのが難しいところです。
それらは短絡的に見ると同じものに見え、冗長性があるように思えてしまいます。
プログラマーは冗長性を見るとすぐ共通化したくなるという病を患っていることがあります。
しかし、これはそれぞれのドメインの成長過程のものであり、必要とする情報や責務を異なることが多いはずです。
逆に言うと全く同じような型やモデルが各モジュールに散らばっているのだとすると、分散モノリスをモジュラーモノリスの中で再現してしまっているという状況ではないかと思います。

分散モノリスに陥りやすい

と言ったように簡単に分割できるということ、また同じ型を使いましたくなる欲求に駆られることなどに起因し
分散モノリス状態を作りやすくなります 。モノリス内の分散モノリス。家庭内別居みたいなことでしょうか。違うか

まとめ

ここまで書いた通り、モジュラーモノリスはとても難しいです。
まずは綺麗なモノリスを作るというのが第1に重要なのかもしれません。
しかし、マイクロサービスで失敗しがちな部分を小さなコストで実施、トライアンドエラーができるという点はモジュラーモノリスの良いところです。

実際に綺麗な設計でモジュールごとに分割されたものはできれば、理想的な疎結合な状態、業務のドメインの単位で独立したコードベースを手に入れることができるかもしれません。
さらに例えばサービスがスケールした時、
モジュールをそのままマイクロサービス化出来たりするというメリットもあります。


モジュラーモノリスは難しい夢でもあり、叶えると強い武器でもあります。
そしてマイクロサービスにしろモジュラーモノリスにしろドメイン立ち向かうということは辛抱強さが必要です。

今回はモジュラーモノリス起点に話を展開しましたが、
本質的には複雑さ、ドメインとチームで立ち向かっていくっていうところなのかもしれません。