• 本来はコーディングに入る前に、設計を考えていく
  • 1から考える必要はなく、先人たちが考えたパターンを参考にしていく
    • SOLID原則は汎用的な指針を提供するが、原始的すぎて具体的にどうしたらいいのかまでは教えてくれない
    • これらを満たすために具体的にどうしたらいいかを先人が教えてくれるのがアーキテクチャである
  • 自分達のシステムに合わせてカスタマイズしていく
    • 考えたアーキテクチャは図で可視化して、他人と議論しやすくする
  • 最初から正解に辿り着こうと思わず、開発を進めていく中で理想的なアーキテクチャに近づけていく
    • 後からアーキテクチャを変更できるように作っておくことも重要

      アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。(Neal Ford)

• 以下が達成されるようなルールを考え、変更しやすいシステムを作る
  • ソフトウェアが持つ複雑性を軽減させる
    • 業務で扱うようなシステムは仕様がややこしい
    • 問題を細かく分割して、人間にとって考えやすくする
    • 将来的な変更や拡張への柔軟性を確保する
  • 分割した要素同士の関係性をコントロールする
    • 要素の関係性を整理して、変更の影響度を小さくする
  • 設計段階で品質を保証する
    • パフォーマンス、保守性、信頼性などの非機能要件に関わる品質を確保する
    • コーディングルールを共通認識化できる
• アーキテクチャの例
  • クリーンアーキテクチャ
  • レイヤードアーキテクチャ
  • ヘキサゴナルアーキテクチャ
  • MVCアーキテクチャ
  • MVVMアーキテクチャ

クリーンアーキテクチャ

graph LR
  Model --> Controller
	Controller --> Model
  View --> Controller
	Controller --> View

MVCアーキテクチャ

• どのパターンも共通しているのは、
  1. 責務を考え分離する
  2. 依存関係を考える

ということである。