Design doc

ソフトウェア、プロジェクトの設計本。

• 機能別分解をしてはいけない。変更への対応が難しいから
• 変動性に基づいて分解せよ
  • 変更される可能性がある領域を明らかにし、その部分をサービスやシステムの部品としてカプセル化する
• 分解の重要な基準、機能ではなく変化を探す
• 要件分析の目的は、変動領域を見つけること
• 変動性と可変性の違い
• 変動性の軸が見つからないようなものはカプセル化してはならない。システム内とのコンポーネントとの関連を質問してはならない
• 1人のユーザが同じコンポーネントを永遠に使っていられるだろうか。答えがノーなら、それはなぜか
  • 時間の経過とともにその顧客が何かを変えたくなることがわかっている場合が多い。そして変えたくなる何かをカプセル化する
  • すべての顧客が、↑で作ったシステムを使えるかどうかを自問自答する。答えがノーなら、顧客によって変えたくなる部分がどれかをはっきりさせ、それをカプセル化してさらにシステムを作る
  • 変動性の軸にひっかかるすべてのものがカプセル化されるまで、このような形でデザインを切り分けていく
• 軸はほとんど必ず独立していなければならない。時間とともに1人のユーザで変わることは現時点のすべてのユーザで違っていることはないはずであり、逆も当てはまる
• 自分の家を見て、時間とともに何が変わったかを観察する。家具のアレンジは変わり、一部は新しいものに置き換わっている。家具は家の中の変動領域だという結論が得られる。電化製品、家の住人は変動領域だ
• ほとんどの要求仕様には要件を装うソリューションが溢れかえっている。機能別分解は苦痛を最大限まで拡大する
• 変動領域の可能性があるもののリストを作る

トレーディングシステムの例。

• フロント
  • Webポータル
  • トレーダーアプリA
  • トレーダーアプリB
• トレードワークフロー(ロケール)
  • 取引の細部は変わりうる
  • ワークフローの収納というオペレーションコンセプト
  • 取引対象ごとに別々の取引ワークフローを持てる
  • ロケールごとに異なるワークフローを持てる
  • 複数のマシンとセッションにまたがって長時間実行されるワークフローをサポートできる
  • 接続されたシングルセッションの取引と長期に渡って実行される分散トレードが同じように扱われる。対象性と一貫性は望ましい性質である
• 分析ワークフロー(ロケール)
  • 市場データの形式上や値の変動性
• 通知
• フィード受信
  • 社内
  • 社外
    • A, B, C,…
• トレードアクセス
• ワークフローアクセス
• 顧客アクセス
• フィードアクセス
• トレードストレージ
• ワークフローストレージ
• 顧客ストレージ

ビジネスの本質は変動しない。ビジネスの本質が変わるなら、古いシステムを壊して最初からやり直すことが許容される。

• 日常的によく使っているソフトウェアシステムで練習する
• 自分が携わった過去のシステムを再検証する
• ユースケースの図による表現としてはアクティビティ図を推奨する
• アクティビティ図とユースケース図を混同しない
  • アクティビティ図は時間をシーケンスを表現できる
  • ユースケース図はユーザ中心で時間やシーケンスを表現できない
• ユースケースは顧客と時間の両方で変動性をはらむ
• シーケンスとアクティビティの両方に変動性がある
• クライアントの変動性は激しい。クライアントに求める動作はエンドユーザごとに違ううえに、異なるデバイスで同じことをしたいというユーザもいる
• 「要件に合わせてデザインしてはならない」
• 要件をつかむ方法として正しいのはユースケースという形を使うこと。システムに求められるふるまいを集める
• 完全な要件セットを集め、それに合わせてデザインしても無駄
• あらゆるシステムデザインの目的は、すべてのユースケースを満たせるようにすること。「すべて」とは、現在/未来の既知/未知
• 要件が変わったときに変えなければならないようなデザインは、まずいデザイン
• コアユースケースはすべての顧客が共有する
• 組み合わせればすべてのユースケースを満たせるようなコンポーネントの最小セットを見つけること。ほかのユースケースはすべてコアユースケースの変種
• ユースケースを満たすことを目標としないのは、誤りや見落としを含む可能性があるためではない。ユースケースは変わるものだから
• シーケンス図は複雑なユースケースを説明するのに適切なツールであることが多い
• システムが10個程度のコンポーネントの組み合わせで必要なふるまいをサポートするなら、膨大な組み合わせを作ることができる
  • ノートPCはワープロ機能を提供してくれているが、ノートPCのアーキテクチャに含まれるコンポーネントのなかにワードプロセッサという機能は含まれていない。キーボード、画面、ハードディスク、バス、PC、CPUのインテグレーションによってワードプロセッサの機能を提供している
• 機能別分解が変化の影響を最大まで大きくする。デザインが機能を基礎としていれば、変化は1箇所に留まらない

実例。

• コアユースケースを探すために、まずは入力や収集、分配といった低水準のユースケースは無視した
• コアユースケースはシステムの存在意義である職人のマッチングユースケースのみ
• スイムレーンを使ったアクティビティ図の分割
• 最悪のシステムデザインをわざと作るアンチデザインの試み
  • モノリス
  • 粒度の細かいコンポーネント
  • ビジネスロジックが入り込み肥大化したクライアント
  • サービスの連鎖的呼び出し
  • ドメイン別分割
• あらゆるデザイン作業の指導原理はビジネスに奉仕すること
• ビジョンを策定する。アーキテクチャから所要時間、コストなどの条件を動かしていかなければならない
• ビジョン最優先という方針は、合意したビジョンと無関係な要求を拒絶するすばらしい手段になる
  • 例: 「TradeMeの市場をサポートするアプリケーションを構築するためのプラットフォーム」
  • ビジョンは法律の条文のように読めるものにするべき
  • プラットフォームというマインドセットは、会社が熱望していた多様性と拡張性を意識させるために役立った
• ビジョンの合意ができたら、ビジョンに沿って具体的なビジネス目標を箇条書きにしていく
• ビジネス目標のリストを作るときには、ビジネスサイドの視点を取り入れるようにすべき
  • 例:
  • リポジトリとアプリケーションの統一
  • 新しい要件への機敏な対応
  • 国や市場の違いを吸収できる高度なカスタマイズのサポート
  • 完全な可視性と説明責任の実現
  • 技術・規制の動向の先取り
  • 外部システムとインテグレーションしやすい
  • セキュリティの整備
• ビジョンとビジネス目標を言語化しただけでは不十分なことが多い。ミッションステートメントも用意すべき
  • 例: 「組み合わせることで開発チームがアプリケーションや機能を生み出せるソフトウェアコンポーネントのコレクションをデザイン、構築する」
  • ミッションとして開発する機能を明示しなかった。ミッションは機能を構築することではなく、コンポーネントを構築すること
  • これでビジネス的に正しいアーキテクチャをデザインせよという指示を出させることに成功した
  • アーキテクチャとビジネスのビジョン、目標、ミッションステートメントの歩調を揃えることによって、ビジネスにとって正しいアーキテクチャを受け入れさせるのが楽になる
  • ビジネスサイドの人々にアーキテクチャ策定を支持してもらいたければ、アーキテクチャがどのようにしてビジネスに貢献するかを具体的に示さなければならない
• 言葉の曖昧さをなくすため、システムデザインの作業に取り掛かる前に、ドメインの簡単な用語集を作り、全員が同じ前提で考えられるようにする
  • 用語集を作る最初の段階では、「誰」が「何」を「どのように」「どこに」という当たり前の問いに答えていくとよい
• プロジェクトを変動領域とすることにはドメイン別分解の臭いがある。コアの変動領域は、プロジェクトではなく市場である
• 規模によってプロジェクトのワークフローが異なる可能性がある
• プロジェクトのニーズに合った職人を見つける方法の変動性はカプセル化される
• 探索の基準とその定義の変動性はカプセル化される
• デプロイモデルは変動性。データを特定の地理的な位置から外に出せないとき、システムの一部または全部をクラウドにデプロイする場合がある
• プロジェクトの分析はさまざまな方法でできるべきである。明らかに変動領域

システムデザインの次はプロジェクトデザイン。

ソフトウェアプロジェクトのニーズの階層構造。

• 物理的条件
• 安全の条件
• 反復可能性
• 工学的条件
• 技術的条件

できるプログラマはDesign documentを先に書くらしい。 あとで書くのはつまらないし、頭の中が整理される。

実際のOSSのゲームの例。