アーキテクチャ

アーキテクチャとは

ソフトウェアアーキテクチャとは、システム全体をどのような要素 (コンポーネント) に分割し、それらをどう関係させるかを決める、最上位の構造設計だ。建築の設計図に例えられることが多く、個々のコードの書き方ではなく「システム全体の骨格」を扱う。この骨格の選択が、性能・拡張性・保守性・開発体制までを長期にわたって規定する。

代表的なスタイル

スタイル	特徴
モノリシック	全機能を 1 つのアプリにまとめる
マイクロサービス	機能ごとに独立したサービスに分割
レイヤード	表示・業務・データの層に分ける
イベント駆動	イベントの発生を起点に処理を連携
ヘキサゴナル	業務ロジックを中心に置き、UI・DB・外部サービスを差し替え可能な接続口として外側に配置

どれが優れているということはなく、システムの規模・チーム構成・変更頻度に応じて選ぶ。また、これらは排他的な選択肢でもない。ヘキサゴナルの原典での名称は「ポートとアダプター」で、Alistair Cockburn が 2005 年に公開した文章で示された。その狙いは、利用者からでも別のプログラムからでも自動テストからでも同じように動かせて、実行時のデバイスやデータベースから切り離して開発・テストできる状態を作ることにある (詳しくは ポートとアダプター)。1 つのマイクロサービスの内部をヘキサゴナルで組み、サービス間はイベント駆動で連携する、といった重ね方が実際には普通に起きる。

なぜ重要か

アーキテクチャ上の判断は、後から覆すコストが極めて大きい。例えばモノリシックからマイクロサービスへの移行は、コードの書き換えにとどまらず、運用・監視・チーム分割まで影響する。だからこそ、目先の実装しやすさではなく、システムが将来どう成長するかを見据えて決める必要がある。

過剰分割という罠

マイクロサービスは、James Lewis と Martin Fowler が 2014 年 3 月に特性を整理した記事以降広く注目されたが、小規模なシステムに最初から細かく分割を適用すると、サービス間通信の複雑さ・障害切り分けの困難さ・運用負荷だけが増え、利点を得られないことが多い。「まずモノリシックで始め、ドメインの境界が見えてから分割する」判断 (Fowler が 2015 年 6 月の記事で説いた「モノリスファースト」) が、現実には堅牢なことが少なくない。判断の目安になるのは、分けた単位でチームが独立してデプロイできるか、障害が起きたときに影響範囲をその単位で切り離せるかである。この 2 つを満たさない分割は、境界を越える呼び出しが増えるだけで、モノリシックより脆くなる。アーキテクチャは流行ではなく、解くべき問題から逆算して選ぶものだ。

考え方を学ぶには関連書籍が役立つ。