ソフトウェアアーキテクチャ
ソフトウェアアーキテクチャのモチベーション
-
以下が達成されるようなルールを考え、変更しやすいシステムを作る
-
ソフトウェアが持つ複雑性を軽減させる
- 業務で扱うようなシステムは仕様がややこしい
- 問題を細かく分割して、人間にとって考えやすくする
- 将来的な変更や拡張への柔軟性を確保する
-
分割した要素同士の関係性をコントロールする
- 要素の関係性を整理して、変更の影響度を小さくする
-
設計段階で品質を保証する
- パフォーマンス、保守性、信頼性などの非機能要件に関わる品質を確保する
- コーディングルールを共通認識化できる
-
ソフトウェアが持つ複雑性を軽減させる
-
アーキテクチャの例
- クリーンアーキテクチャ
- レイヤードアーキテクチャ
- ヘキサゴナルアーキテクチャ
- MVCアーキテクチャ
- MVVMアーキテクチャ
graph LR Model --> Controller Controller --> Model View --> Controller Controller --> View
アーキテクチャの導入
-
本来はコーディングに入る前に、設計を考えていく
-
1から考える必要はなく、先人たちが考えたパターンを参考にしていく
- SOLID原則は汎用的な指針を提供するが、原始的すぎて具体的にどうしたらいいのかまでは教えてくれない
- これらを満たすために具体的にどうしたらいいかを先人が教えてくれるのが アーキテクチャ である
-
自分達のシステムに合わせてカスタマイズしていく
- 考えたアーキテクチャは図で可視化して、他人と議論しやすくする
-
最初から正解に辿り着こうと思わず、開発を進めていく中で理想的なアーキテクチャに近づけていく
-
後からアーキテクチャを変更できるように作っておくことも重要
アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。(Neal Ford)
-
後からアーキテクチャを変更できるように作っておくことも重要
-
1から考える必要はなく、先人たちが考えたパターンを参考にしていく
⇒ 細かいことは WEBアプリ回 でやるのでお楽しみに!
アーキテクチャの共通思想
-
どのパターンも共通しているのは、
- 責務を考え分離する
- 依存関係を考える
ということである
まとめ
ソフトウェアアーキテクチャ
ソフトウェアが持つ複雑性の軽減
分割した要素同士の関係性コントロール
設計段階で品質の保証
どのパターンも共通しているのは
- 責務を考え分離する
- 依存関係を考える