やったこと

• Design It! 8章 意味のあるモデルで複雑さを扱う 読了

学んだこと

ポイント

• アーキテクチャモデルを構築するメリット
• アーキテクチャのメタモデルを作成する目的
• アーキテクチャモデルをコードに盛り込むための手段

学び

• アーキテクチャモデルを構築 & 更新し、アーキテクチャの理解を促進する
• アーキテクチャのメタモデルを記述し、アーキテクチャモデルの理解を促進する
  • 新しい概念をブラッシュアップし概念を固めていく
  • 概念の更新に合わせて、メタモデルに矛盾が生まれないよう規則を更新する
  • 良い名前を使う
• アーキテクチャモデルをコードに盛り込むために、以下のような手段がある
  • コードの命名に、アーキテクチャモデルの語彙を使用する
  • 品質特性を損なうようなコーディングが出来ないようにする
    • ツールで強制できる状態がベスト
    • 時点で規律や戒めに頼る
  • コメントにて、設計根拠を説明する

所感

アーキテクチャの一面を説明するモデルとして、アーキテクチャモデルは役に立つ。
概念、規則、メタモデルなど、モデルをうまく説明するための定義がいくつか登場。
全体的に抽象的な話が多く、理解が難しかった。
うっすらイメージできるレベルで、人に説明できるレベルまで理解できているとは言えない。
何か一つ、説明できるような例を経験したり思いついたりすると全然違うと思う。

メモ

ソフトウェアは、多かれ少なかれ複雑さを抱える。
解く問題が難しいほど、後から機能を足すほど、ソフトウェアは複雑になっていく。

複雑さを抑えるために何ができるか見ていく。

アーキテクチャを見通す

アーキテクチャをうまく説明できる、新しい抽象概念を作成する。
新しい抽象概念は、図と同じように、アーキテクチャのある一面を説明する。
優れた抽象概念は、アーキテクチャを正確かつ精密に説明できる「アーキテクチャモデル」となる。

優れたアーキテクチャモデルの利点を示す。

• 設計の語彙を確立する
  • アーキテクチャモデルを指す言葉で会話ができる
• 関心を持つべき細部に注意を向ける
• 品質特性やその他のシステム特性を見通せる
• アーキテクトの意図を記録できる
  • なぜモデルに書いた方法を選択したのか、モデルの背後にある意図を表現できる

全てのモデルには、「概念」と「規則」がある。

メタモデルを記述する

アーキテクチャのメタモデルは、モデルの「概念」と「規則」を定義する。

![[Drawing 2024-01-09 20.17.26.excalidraw]]

概念は、アーキテクチャにおける要素や関係になる。
概念を定義したら、その概念を使用するための規則を設定する。

新しい概念を固定化する

新しいアイデアから、概念を定義する。
アイデアのブラッシュアップに合わせて、概念も更新していく。
アイデアが固まってくれば、概念が固まってくる。
十分に固まった概念は、概念を指す言葉で意思疎通が可能になる。

矛盾を調整する

新しい概念を追加したり、パターンをマージすると、規則に矛盾が生まれることがある。
矛盾は、アーキテクチャの一貫性を損ない、メタモデルを見た人に誤解を与える。
そのため、生まれた矛盾はうまく調整する必要がある。
つまり、新しい概念を追加したり、パターンをマージする場合、矛盾が生まれないよう規則の更新も必要となる。

また、規則には、アーキテクチャに課すと決定した「概念上の制約」も記述する。
これにより、特定の品質特性を促進できる。
（概念上の制約を維持している限りは、特定の品質特性を維持できる ... という考え方）

良い名前を使う

良いコードに良い名前が必須なのと同じように、良いアーキテクチャにも良い名前は必須。
アーキテクチャの場合、問題の理解が深まるほど、概念に付ける名前も変化する。
名付けには、7段階ある。

No	ステージ	名前（例）
1	名無し	何かをするもの
2	無意味	クランベリー
3	的確	ジョブスタータープロセス
4	的確かつ完全	データフェッチャー、チェッカー、トランスフォーマー
5	適切な行い	データ変換ジョブランナー
6	意図	データプリペアラー
7	ドメイン抽象	データ準備エージェント

コード内にモデルを構築する

モデルはアーキテクチャの見通しを良くする。
構築したモデルの名前をソースコードに持ち込むことで、アーキテクチャとソースコードが関連するようになり、理解の促進につながる。
他にも、以下のような利点がある。

• 概念的な設計の一貫性を維持し、望む品質特性の維持に貢献できる
• モデルとコードの足並みがそろい、理解が容易になる
• ドキュメントの必要性がいくらか軽減する

アーキテクチャの語彙を適用する

アーキテクチャでは、レイヤーやサービス、フィルターについて表現する。
コードでは、パッケージやクラス、メソッドを実装する。

アーキテクチャの抽象概念をコードに移行する際、用語を揃えないと、混乱の原因となりかねない。
用語を揃えるためには、コードに、アーキテクチャの語彙を使用すると良い。

例）

• レイヤーパターンを使用する場合は、コードパッケージをレイヤーと呼ぶ
• パイプとフィルターパターンを使用する場合は、クラス名に「パイプ」や「フィルター」を使用する
• システムメタファーとしてパイロットやナビゲーターといった単語を使っている場合、単語や型の名前に使用する

要素間の関係を強制する

コードの構成は、コード内のアーキテクチャ構造に大きな影響を与える。

言語仕様（パッケージプライベート、アクセス修飾子など）を活用し、品質特性を損なうようなコーディングが出来ないよう強制できる状態がベスト。

強制できない部分は、規律や戒めに頼ることになる。

• 静的ツールによる、違反の検出
• 契約による設計 & アノテーション
• マイクロサービスなどで、実装を完全に隠蔽

コメントとしてヒントをつける

強制や規律の背景を説明するために、コメントは有効。
特に、コメントは設計根拠の説明に有効。
設計ドキュメントへのリンクを貼るだけでも効果的。