Open2

【読書感想文めも】ソフトウェアアーキテクチャの基礎(1部 5章)

sataksatak

5章 アーキテクチャ特性を明らかにする

序文

特性を明らかにすることは下記作業の前の大事なステップ

  • アーキテクチャを作成する
  • 既存のアーキテクチャの正当性を判断する

まずは特性を明らかにしないと何も始まらないってこと

特性を明らかにするためのヒント・着目点

  • ドメインの関心事
  • 要件
  • 「暗黙的」なドメイン知識

5.1 アーキテクチャ特性をドメインの関心事から捉える

ドメインのステークホルダーと協力してアーキテクチャ特性を定義する際は、
サポートするアーキテクチャ特性の数を「可能な限り」絞ろう。

逆にたくさんサポートした結果「汎用アーキテクチャ」を作ってしまうのはアンチパターン
→設計が複雑化するため(n回目)

設計はシ　ン　プ　ルに行こう！

■特性をどう選択する？

アプリケーションうやシステムがサポートしなければならないアーキテクチャ特性の最終的なリストに「優先順位」をつけたがるアーキテクト・ステークホルダーは多い。
が、この作業は時間の無駄だし・ステークホルダーとの不必要な摩擦や意見の相違を生む。
これはよろしくない。

ではどうするか。

より良い方法は、主なステークホルダーに最終的なリストから最も重要な上位3つの特性を（順位をつけずに）選んでもらうことだ。

【メリット】

  • この方が合意に持って行きやすい
  • 何が最も重要かについての議論を促進できる
  • アーキテクトが重要なアーキテクチャ決定をする時のトレードオフ判断の良い材料になる

アーキテクチャ特性を「翻訳作業」で決定する

アーキテクチャ(エンジニア)←→ステークホルダー(ビジネスサイド)
同じ目標に向かっているもの同士なのに、それぞれが語る言語(文脈というべきか？)は異なる。
会話が噛み合わないのはよろしくない。

ではどうするか(2回目)
ちょうどいい翻訳表がある↓

要は、初めから自分たち(エンジニア)の言葉が相手に通じるなんて思わない方がいい。
最初から翻訳機を使ってコミュニケーションを取る前提でやり取りするくらいの認識がちょうどいいってこと？

重要なのは、市場投入(ここでは本番リリースを指していると思われる)までの時間がすなわちアジリティではない、ということだ。

もうひとつ、

市場投入までの時間を満たすには、アジリティとテスト容易性とデプロイ容易性を満たす必要がある。
これは、多くのアーキテクトがドメインの関心事を翻訳する際に陥る罠だ。

5.2 要件からアーキテクチャ特性を抽出する