コードの構造化 - システムに組み上げる
これまで３回に渡ってコードの分割、分割したコードの結合、そしてグループ化について見てきた。
グループ化してリリースされたコードは他のパッケージやライブラリ、外部システムと組み合わされて「システム」になる。
ではシステムはどうやって組み上げればいいのだろう？なんとなく各所から出来上がってきたものや偶然見つけたオープンソースを組み合わせればいいのだろうか？
各コンポーネントの組み合わ方を考えるのがアーキテクチャだ。このアーキテクチャレベルになるともはやコードは見ていない。今までとは粒度が大きく異なる世界だ。今回は締めくくりとしてアーキテクチャについて簡単に触れておこう。
アーキテクチャ
- システム、ソフトウェアの基本的な設計概念
- もともとは建築におけるデザインや設計思想のこと
- システムの抽象化された像を検討する
- コンポーネント間のやり取り、関係性に着目する
- 実装の詳細には触れない
で結局なにを検討するの？
「実装に触れないで一体なにを検討するの？」と思うだろう。下記のようなシステム特性を考慮しつつ適切な必要なコンポーネントとその配置、関係性を検討するのだ。
- 性能（Performance）
- 可用性（Availability）
- 変更容易性（Modifiability）
- テスト容易性（Testability）
- 使いやすさ（Usability）
- セキュリティ（Security）
実装している人から見れば絵に描いた餅を味比べしているような話だがこういうものなのだ。
単体のコードの性能、変更容易性、試験容易性が優れていてもシステム全体のコードの性能、変更容易性、試験容易性が優れているとは限らない。システムとして組み上げた瞬間に突如、試験も変更もできない箇所や性能が顕著に悪い箇所が生まれてしまうかもしれない。そういうことがないように事前にシステムの全体像を検討するのがアーキテクチャだ。
アーキテクチャパターン
案件ごとにアーキテクチャをゼロから検討することはない。様々な案件でよい結果につながったアーキテクチャがパターンとして整理されている。自分の案件に近いアーキテクチャパターンを前提に検討を開始することが一般的だ。利用することが前提のフレームワークが特定のアーキテクチャパターンを強制していることもある。
「アーキテクチャパターンがあるなら検討は不要じゃないの？」と思うかもしれない。デザインパターンがそうであるようにアーキテクチャパターンも全ての事例に対する具体的な回答を提示してくれるわけではない。メリット・デメリットを比較しながら具体的な回答を自分自身で検討し、必要であれば少しパターンに手を加えることも求められる。
以下に典型的なアーキテクチャパターンの名前を示す。
- 階層化（Layered or multitier architecture pattern）
- システムを3階層か4階層程度に分けて構築する
- MVC（Model-View-Controller architecture pattern）
- Webフレームワークに多く見られる
- イベント駆動（Event-driven architecture pattern）
- IOTなどで注目を集めている
- マイクロサービス（Microservices architecture pattern）
- 小さなサービスの疎結合でシステムを構築する
- Space-based architecture
- 独立したProcessing Unitを組み合わせてシステムを構築する
