やったこと

• Design It! 6章 アーキテクチャを選ぶ 読了

学んだこと

ポイント

• アーキテクチャを適切に選択するにはどうするか
• 制約の種類
• 品質特性を考慮してアーキテクチャを選択する
• 要素に機能的責務を割り当てる目的
• 変化を見越して設計する

学び

• アーキテクチャを適切に選択するため、探求プロセスを実施する
  • 問題を解決できるアーキテクチャを列挙する「発散」と、問題に適していない選択肢を排除する「収束」を繰り返す
• 制約には、「技術的」なものと「ビジネス上」のものがある
  • アーキテクチャに影響を与える制約もある
• 列挙したアーキテクチャが、解決したい問題に合う品質特性を得意とするか判断する
• 必須の機能要求を達成したことを確認するために、アーキテクチャ上の要素が負う機能的責務を明文化する
• 変化に対応できるよう設計する
  • 変更に困難が伴う判断を、可能な限り遅らせる
  • 判断を、アーキテクチャの外に移す
    • アーキテクチャではなく、コーディングレベルの設計で判断を下せるよう、アーキテクチャを決定する

所感

ビジネス上の制約は、技術以外でもなんとかできる可能性がある。
どうにもならないのは、与えらた技術的制約。
前の章にもあったが、勝手に変更できないものと思い込むのは危険。
覚えておきたい。

「品質特性を促進していけるような技術やフレームワークを探求する」は、普段無意識にやっていることだと思う。

• 例）「スモールにスタートして価値提供を早めたいから xxx を使用する」

これをうまく抽象化した文だと感じた。

「変更に困難が伴う判断を、可能な限り遅らせる」という話は、違う言葉で何度か目にしてきた。
この辺りはよく知られているテクニックなのだと感じた。

メモ

解決したい問題について学ぶほど、よりニーズに合ったアーキテクチャを選択できるようになる。

• 言い換えると、何も考えず、サイコロを振る感覚でアーキテクチャを選択すると、悲惨な末路を辿る

アーキテクチャ上重要な要求を実現するために、トレードオフを加味して複数のアーキテクチャから一つを選択する。

選択肢を広げるために発散させ、決定するために収束させる

「複数のアーキテクチャが存在する」ことを認識するためにも、考えの発散と収束を行う。

• 発散 : 問題を解決できるアーキテクチャを列挙する
• 収束 : 合意形成によって、問題に適していない選択肢を排除する

発散と収束を繰り返し、最適なアーキテクチャを模索する。
この過程を、書籍では探求と呼称する。

アーキテクチャ上重要なものを探求する

アーキテクトが探求するのは、一般的に以下の分野。

• アーキテクチャ構造の全体構成を決定するために、要素とその役割を探求する
  • 要素の責務を明確化する
  • その過程で責務の無い要素を発見した場合、これを排除する
• 要素が度相互作用するかを決定するために、関係とそのインターフェースを探求する
  • アーキテクチャの要素間を連携させていく手段を探求する
  • REST ? TCP ? 共有メモリ ? GlaphQL ?
• アーキテクチャが形取る世界を理解するためにドメインを探求する
  • 解決したいドメインの独自用語や概念を説明する
  • 解決したい問題領域を深く理解するほど、適切な要素分割と責務割り当てにつながる
• 品質特性を促進していけるような技術やフレームワークを探求する
  • 選択した技術の得意分野と、優先したい品質特性が一致する状況が理想
  • 反対に、不一致したり、フレームワークから外れて得意分野を十全に生かせなくなった場合は良くない
• 出荷を確実にするような構築方法やデプロイ方法を探求する
• 意思決定を導く視点を得るため、過去の設計を探求する

制約を受け入れる

制約には、「技術的」なものと「ビジネス上」のものがある。

与えられた技術的制約は、受け入れるしかない。
自分たちで判断を下した、技術的制約と化したものは、痛みと引き換えに変更は可能。
ビジネス上の制約は、時としてアーキテクチャに影響を与える

• 例 : 納期がタイト
  • 並行開発や設計が簡単（または不要）なアーキテクチャ
  • インクリメンタルなデリバリーを促進するパターン
  • 自動化と開発速度を支援する技術を選択
  • 他、速度を上げるために有用な選択肢
  • 上記選択肢を組み合わせる

また、ビジネス上の制約は、アーキテクチャの外側で満たすこともできる。

• 例 : 予算がない
  • 低コストの下請け業者に発注
  • など

望ましい品質特性を促進する

アーキテクチャごとに、品質特性の得手不得手が存在する。
解決したい問題にて重要視する品質特性を明らかにすることで、重要視する品質特性が得意なアーキテクチャを選択できる。

文献を漁り、パターンを調べると良い。

品質特性という観点では、常に「正しい設計」や常に「誤った設計」というのは滅多にない。
「解決したい問題に合うか合わないか」というだけ。

アーキテクチャが、解決したい問題に合う品質特性を得意とするか判断するために、表にまとめると良い。

品質特性	3層	pub/sub	サービス指向	...
可用性	+	〇	+
パフォーマンス	〇	-	+
セキュリティ	〇	-	〇

++ , + , 〇 , - , --
左に行くほど得意で、右に行くほど不得意

表にまとめることで、議論のたたき台として機能する。

この時、数字ではなく曖昧な記号を用いること。

• 数字を用いると、平均や合計といった、数字をいじることに意識が向きかねない

機能的責務を要素に割り当てる

アーキテクチャの要素ごとに、責務を明文化し、リスト化する。
これにより、必須な機能要求を達成できることを確認する。

基本的に、機能、要素、責務は、1 : 1 : 1 となる。

例

要素	責務
Web UI	WebブラウザでUIを表示し、ユーザー操作を処理する
契約DB	永続ストレージ。契約情報の記録システム

変化に向けて設計する

変化に対応できるようする。
そのために、以下の手段が考えられる

• 変更に困難が伴う判断を、可能な限り遅らせる
  • 言い換えると、適切な時期に設計判断を下す
  • これにより、判断を遅らせることが出来、得られた時間を、よりよいアーキテクチャや技術を選択するための調査や探求に充てることができる
  • 以下の質問に答えることは、適した時期か判断するのに役立つ
    • 判断しないことが進捗を妨げるか？
    • 判断は後回しにできない問題を解決するか？
    • 判断はより多くの選択肢や新しい機会を生み出すか？
    • 判断を遅らせることで、大きなリスクが発生するか？
    • 判断の意味を理解し受け入れるか？
    • 今この判断を下す理由について明確な根拠があるか？
    • 判断が間違っていた場合に、それを取り消す時間があるか？失敗を許容できるだけのゆとりがあるか？
• 判断を、アーキテクチャの外に移す
  • アーキテクチャではなく、コーディングレベルの設計で判断を下せるよう、アーキテクチャを決定する
  • SOLID原則のような、プログラミングパターンから学べる事も多々ある