Zenn
Closed29

Design it!

book
ソフトウェアアーキテクチャ
dak2dak2

アーキテクチャ構造を選択するということは、ソフトウェアシステムで促進したい品質特性をせんたくしているということ

dak2dak2

デザイン思考とは、問題解決のために創造的かつ分析的に人間に注目するアプローチ。

設計判断によって影響を受ける人々に注目することで、解決すべき本質的な問題へとフォーカスする。

デザイン思考の4 つの原則

  1. 人間性の規則（The Human Rule）
    すべてのデザイン活動は究極的には社会的な性質を持つ。
  2. 曖昧性の規則（The Ambiguity Rule）
    デザイン思考者は曖昧性を保全せねばならない。
  3. 再デザインの規則（The Re-design Rule）
    すべてのデザインは再デザインである。
  4. 触感性の規則（The Tangibility Rule）
    手で触れられるアイデアを作ることは常にコミュニケーションを促進する。

Design Thinking: understand - improve -
apply
https://www.slideshare.net/slideshow/design-thinking-understand-improve-apply-by-plattner-hasso-meinel-christoph-leifer-larry-pdf/274152590

dak2dak2

「人間性の規則」

アーキテクトはチームから離れてはならないということも教えてくれる。私たちはチームと協働してアーキテクチャを設計する。ソフトウェアの構築は、極めて社会的な活動

設計とは本質的に人間中心の取り組みだ。私たちは人のためにソフトウェアを設計
する。そして、人と共に設計する。アーキテクチャにおけるあらゆる設計判断は、何
らかの形で誰かの力になるものだ。すべての設計判断は、他の人々に理解され、共有
されなければならない

dak2dak2

曖昧さを保つ

Ruth Malan とDana Bredemeyer は論文「Less is more with minimalist architecture」[MB02] において、アーキテクトは必要最小限のアーキテクチャ（Minimalist Architecture）を設計すべきだと提案

アーキテクチャを必要最小限にするとは、責任を持てる限りにおいて設計判断を遅らせるということだ

必要最小限のアーキテクチャでは、そうした詳細な設計についての判断を、後続の設計者がアーキテクチャの外で行えるように、安全な状態で保留にしておける

dak2dak2

感触性の規則

触感性の規則」は「人間性の規則」と密接に関係している。人々がアイデアを自分のものにするには、そのアイデアに共感できなければならない。つまり、アーキテクチャを共有する唯一の方法は、それをタンジブルにするということ

dak2dak2

問題を取り巻く境界は、潜在的にそれを解決できる解決策によって作られる。問題を理解するには、解決策を探る必要がある。解決策をうまく探求するには、問題に対する理解を深めなくてはならない。ソフトウェアアーキテクチャを設計するには、問題と解決策を同時に考える必要がある。設計プロセスの早い段階でコードを書くことは、問題と解決策の相互関係に対処する1 つ

dak2dak2

ソフトウェアシステムが大きくなればなるほど、前払いのアーキテクチャ設計から

受ける恩恵は大きくなる

Boehm の研究によると、大規模（10,000KSLOC†1）なソフトウェアシステムでは全体の開発スケジュールの37% 以上をアーキテクチャ設計に使うのが賢い判断と評価できる。

小規模（10KSLOC）のソフトウェアシステムでは、前払いのアーキテクチャ策定からはほとんど恩恵を受けられない

書き直した方が早いケースも

アーキテクチャ設計に少ししか投資しないと、強烈なしっぺ返しが来ることが予想される

かけすぎもかけなさすぎも良くない

dak2dak2

リスクや問題の把握

＜条件＞－＜結果＞形式のリスクステートメント

条件は現在の世界に関する事実だ。そして、結果は状態の直接的な結果として将来発生する可能性のある良くないこと

デザインマインドセットとリスクの掛け算

例

統計的に有意な分類器を訓練するにはたくさんのデータが必要だ。スケールするた
めのデータストレージのコストは利益に見合わないかもしれない
　デザインマインドセット：作成。
　私たちがしたこと：コスト見積のモデルを作成した。このモデルでは、設計の選択肢ごとの良い点悪い点をステークホルダーに示した。バックログの優先順位を変更することで、リスクの期間を短縮した。
保持するデータには顧客の機密情報が含まれている可能性がある。そのため、提供
できるものよりも厳密なデータ分離が必要になる可能性がある
　デザインマインドセット：評価。
　私たちがしたこと：利用可能な計算プラットフォームを、どの程度ニーズを満たしているかという観点から評価した。

エンジニアリングリスクは、何を設計するかを決めるのに役立つ。デザインマインドセットはリスクを減らす戦略を立てるのに役立つ

軽減する必要のあるリスクに直面した場合、まずリスクのどの部分（条件、影響、確率、期間）に対処できるかを決定する。そして、次にデザインマインドセットを選択

dak2dak2

4 章 ステークホルダーに共感するでは、誰がソフトウェアシステムの影響を受けるか、そして彼らがなぜそれを気にするかを明らかにする方法を学んだ。

5 章アーキテクチャ上重要な要求を掘り下げるでは、ソフトウェアアーキテクチャの観点から、何を、つまり要求を定義する方法を学んでいく

dak2dak2

アーキテクチャ上重要な要求（Architecturally Significant Requirement：ASR）とは、アーキテクチャ構造の選択に強く影響する要求のことをいう。ASR を明らかにするのは、ソフトウェアアーキテクトの責任だ。これを行うには、次の4 つの要求分類について考える必要がある

制約
変更できない設計判断。通常は与えられるものだが、選択することもある。

品質特性
システムが特定の状況でどのように動作するかを特徴付ける、外部から観察できる

影響を与える機能要求
アーキテクチャにおいて特別な注意を必要とするフィーチャーや機能。

その他の影響を及ぼすもの
時間、知識、経験、スキル、社内政治、あなた自身の余計なバイアス、そして意思決定を左右するその他すべてのもの

dak2dak2

制約が現れてくるにつれて、それが作り出した制約なのか与えられた制約なのかを注意して区別するようにしよう。難しいかもしれないが、制約のある設計判断を変更するという選択肢は常に存在する

所感

分かる。思考を経て、優先すべき制約が変化するケースはある。

dak2dak2

アーキテクチャに関する意思決定を左右するのは、アーキテクチャ上重要な要求（ASR）、特に品質特性

dak2dak2

ソフトウェアアーキテクチャを設計するとは、つまりは不確実性のもとで決定を下すということだ。設計判断にはトレードオフが含まれる

適切に設計されたアーキテクチャでは、すべての要素には明確な責務がある。明確に定義された責務のない要素はすべて排除されるべきだ。設計の選択肢を検討するには、さまざまな責務を持つ要素の組み合わせを検討する必要がある。

dak2dak2

設計者はソフトウェアシステムの品質特性を促進するための構造を選択する。構造を選択するための最も一般的なやり方は、パターンを調べることだ。すべての設計は再設計だということを肝に銘じよう。

所感

既存のプロダクトコードもだし、一般的なプラクティスもそう。

dak2dak2

意思決定マトリクスは、アーキテクチャ設計の選択肢をざっとトレードオフ分析するためのシンプルなツールだ。私たちは、ステークホルダーに設計判断のトレードオフについて強く議論をしてもらいたいの

所感

複数案の比較はするけど、ちゃんとマトリクス作ったことないな。トレードオフについて強く議論してほしいという観点はとても良い。

dak2dak2

6.5.1 拘束力のある判断を最大責任時点まで延期する

簡単に元に戻せない決定、つまりアーキテクチャ上の設計判断は、重大だ。行き詰まることや方向間違いを避ける1 つの戦略は、責任を持てる限り拘束力のある判断を遅らせることだ。決定しなくてはならなくなるまで設計判断を遅らせることは、調査や探求の時間を生み出すことにつながる。

設計判断を下すのに適した時期かを見極めるのに役立つ質問を次に示す。
● 判断しないことが進捗を妨げるか？
● 判断は後回しにできない問題を解決するか？
● 判断はより多くの選択肢や新しい機会を生み出すか？
● 判断を遅らせることで、はるかに大きなリスクが発生するか？
● 判断の意味を理解し受け入れるか？
● 今この判断を下す理由について明確な根拠があるか？
● 判断が間違っていた場合に、それを取り消す時間があるか。失敗を許容でき
るだけのゆとりがあるか？

dak2dak2

6.5.2 設計判断をアーキテクチャの外に移す

設計判断を後から変えるのが容易なのであれば、それはもはやアーキテクチャ上の関心事ではない。可能であれば、変更の可能性がある部分については後続の設計者が設計判断を下せるよう、アーキテクチャを設計しよう。

所感

今判断しなくて良いものは何か

dak2dak2

エンジニアは一般的な問題の解決策を再利用可能なパターンとして捉えてきた。ソフトウェアエンジニアもこの伝統に従っている。経験豊かなソフトウェアアーキテクトは多くのパターンを知っている

所感

ほんとにそう

dak2dak2

パターン

  • Layers
  • Port and adapters
    • ヘキサゴナルアーキテクチャ
    • 核となるビジネスロジックを分離するパターン
  • Pipe and Filter
  • Service-Oriented Architecture
    • 独立したコンポーネントが特定の機能を提供するサービスとして実装されている。実行時にサービスを組み合わせ、ソフトウェアシステムの動作を定義する
  • Publish-Subscribe
    • プロデューサーとコンシューマーは独立して存在し、互いを認識しない。多くのコンシューマーが、それぞれのプロデューサーによって発行（パブリッシュ）されたイベントを購読（サブスクライブ）している。プロデューサーとコンシューマーは、イベントバスを介して間接的に通信する
  • Shared-Data
    • 複数のコンポーネントが共通のデータストアを介してデータにアクセスするパターンだ。一つのコンポーネントがデータまたはデータストアに対して完全に責務を負うことはない
  • Multi-Tier
    • 多層パターンでは、実行時の構造を論理的なグループにまとめる。そして、そうした論理的なグループを、サーバーやクラウドプラットフォームといった特定の物理コンポーネントへと割り当て
dak2dak2

アイデアを共有する最良の方法は、それをタンジブルにすること

所感

この図分かりやすい
状況に応じてタンジブルな形式を

まず口頭で。その後概要。
詳細な資料は書きたくない。更新面倒

dak2dak2

アーキテクチャの評価もテストピラミッド的に行うと良い
数分で終わるクイックチェック。ユニットテストのよう
ピラミッドの上に行くほど、コストのかかるe2eのような時間をかけたチェック。
その間は対象を絞ったチェック

所感

この考え方は他のところでも使えそう

dak2dak2

14章の内容は思考現状整理のFWとしても重要 p229

長いので書かないが適宜振り返りたい

dak2dak2

15章は設計パターンや解決策を検討する際に有用 p265

dak2dak2

16章は決まった設計をタンジブル、可視化して表現、共有する際に有用 p301

dak2dak2

17章は決まった設計を評価する際に有用 p329

dak2dak2

全体所感

アーキテクチャ設計の進め方や考え方にフォーカスしている印象
考えをまとめたり周りを巻き込んで進める際のプラクティス集という印象を持った
考え方のFWは参考にできる部分が多々あるので、進め方に迷ったら見返したい一冊

このスクラップは10日前にクローズされました