BaHo Advent Calendar 2020 19 日目担当の BaHo 猫 です。
近年、マイクロなソフトウェア設計が流行ってますね。 なぜマイクロな設計はモノリシックな設計に比べて良いと言われているのか自分の思考をまとめました。
なぜ設計をするのか
ソフトウェア開発において、「設計」というものは必ず行われます。 では開発者は一体なぜ設計という行為をするのでしょうか。
多くの場合、設計は実装の見通しを立てるだけでなくビジネス要件に合わせて運用・保守や拡張を実施しやすいソフトウェアの構造を作ることを目的としています。
構造を作るとは
ソフトウェアの構造において、保守運用や拡張がしやすい構造を作るというのはつまりどういうことなのでしょうか。
一般的にはモジュール化をすることによってそれらの特性が得られると言われています。 モジュール化とは、コードの関心をモジュールというコードブロックの最小単位で分割して高凝集低結合な状態にすることです。 関心毎にコードを分割していき、最終的には 1 つの関心につき 1 つのモジュールが完成します。 モジュールはその内部で複数の関心を気にする必要がないため、複雑さが限りなく低くなります。
モジュール化の理念から考えると、構造を作ることはつまりコードを分割して複雑さを除去するという解釈ができます。
分割の粒度
保守・運用や拡張をしやすくするためにコードの分割をするという話でしたが、どのようにしてコードを分割するべきでしょうか。
例えば、同じコードベース内で関数の単位をできるだけ意味のある最小単位へ切り出すといった手法があります。 関数粒度を一切考えない非構造的なコードと比較するとコードの前後関係が追いやすく、拡張性は増したように感じます。 一方で保守・運用のしやすさについてはどうでしょうか。 コードの前後関係が追いやすくなったことで保守性はある程度担保されているような気はしますが、運用のしやすさにコードの追いやすさは関係しません。 では、運用のしやすさとは一体何によって決まるのでしょうか。
分割統治
運用は主に、そのソフトウェアが実際に稼働しているかどうかに関心があります。 そのため、運用の視点から見ればどれだけ内部でコード分割がされていようとも先ほどのコードは大きな一つのソフトウェアにしか見えないのです。
この関心を分割するためには、デプロイの単位を複数に分割する必要があります。 機能ごとに分離されたソフトウェアとして稼働していれば、運用者は今見ている機能だけにコンテキストを絞って問題の解決に当たれるのです。
このように関心ごとに分割してデプロイできるソフトウェアは「マイクロサービスアーキテクチャ」と呼ばれていることで有名ですね。
終わりに
昔のソフトウェア設計はあくまで開発にかかるものだけを視野に入れてきたのに対して、近年の設計者はよりサービスが長生きするように運用側の知見も取り入れた設計をするようになったんですかね。
もしくは最近のサービスは複雑なものが多すぎて運用まで考えないと破綻するからでしょうか。
技術的成長によるものか現状適応の結果か、鶏卵な話なのでどちらだと思うかはご自身で決めてください。