まとめ
- アーキテクチャは 変更を容易にする ためにあり、プログラマに対して 適切な制約 をかけるものです
- 型を使うことで、 変数の値を制約 し、想定外の値の混入を防ぐことができます
- モジュール分割を行うことでテストパターンを減らすことができます
- インターフェースを使うことで アクセス方法を制約 し、入れ替えを可能にします
- 先人の考えたアーキテクチャパターンに沿うことで、適切な責務の分割が可能になります
覚えておいてほしいこと
-
アーキテクチャに
絶対はありません
- これを使えばいついかなる時でもOK、みたいな魔法のアーキテクチャは存在しません
- 取り扱うシステムの性質・規模・改修頻度などを見て選択・検討していく必要があります
-
教条主義的にならないでください
-
特定のアーキテクチャ
パターン
を採用することが目的にならないようにしてください
- 何を目的にやっているのか？それはシステムに適しているか？を考えることが重要です
-
ただしオレオレ実装をする前に、一般的にどうやっているのかを調べるようにはしてください
- オレオレ実装は後の人が理解しづらく、レガシー化しやすくなります
-
特定のアーキテクチャ
パターン
を採用することが目的にならないようにしてください
-
数年先のことを考えましょう
- 開発はスタートでしかありません
- 数年後に色々忘れた自分や、新しいメンバーが運用していけるか？を意識しましょう
-
アーキテクチャを考えるだけでなく、それを説明し継承できるようにしましょう
- ex) Design Docs、Architectural Decision Records(ADR)、…etc
設計を学びたい人に
Clean Architecture 達人に学ぶソフトウェアの構造と設計
KADOKAWA / Robert C.Martin / 2018 (原著: 2017)
-
変更を容易にするために今まで考えられてきた考え方や概念を網羅しています
- モジュールなどの考え方ももっと詳しく解説されています
- 1つ1つの内容は薄いので、これを入り口にして、わからない部分を調べてみるのが良いでしょう
- 実践的な内容は少ないので、あくまでも考え方を体系的に学ぶ本です
A Philosophy of Software Design
Yaknyam Press / John Ousterhout / 2018
- 英語only
- 上記のClean Architectureより新しく、一部で相反する内容を含みます
- 両方読んで比較するのがベター
良いコード/悪いコードで学ぶ設計入門
技術評論社 / 仙塲大也
- 実践的なプラクティスとしてはこっち