ビヨンド ソフトウェア アーキテクチャ
ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)
翔泳社
著者:Luke Hohmann
訳者:岡澤裕二、和智右桂
マーチン・ファウラーによる序文
ガイ・カワサキによる序文
まえがき
日本語版への賛辞
第1章:ソフトウェアアーキテクチャ
1.1 ソフトウェアアーキテクチャの定義
1.2 ソフトウェアアーキテクチャに関する一考
サブ゚システムは依存性を管理するために設計される
サブシステムは人間のやる気や願望に応じて設計される
より上位のアーキテクチャヘの屈服
美は見る者の目に宿る
1.3 なぜソフトウェアアーキテクチャが重要なのか
寿命
安定性変更の度合いと性質
採算性
社会的構造
境界を定める
持続可能で、圧倒的な優位性
1.4 アーキテクチャの構築
1.5 パターンとアーキテクチャ
1.6 アーキテクチャの進化と成熟:フィーチャをとるかケイパビリティをとるか
1.7 アーキテクチャヘの配慮と手入れ
技術動向
技術的負債
既知の不具合
ライセンスの遵守
1.8 一に原則、二に原則、三に原則
カプセル化
インターフェイス
疎結合
適切な粒度
高凝集
パラメータ化
遅延
1.9 アーキテクチヤヘの理解を深める
1.10 チーム
1.11 まとめ
チェックリスト
やってみよう
第2章:プロダクト開発入門
2.1 プロダクトマネジメントとは何か?
2.2 なぜプロダクトマネジメントが重要なのか
2.3 プロダクト開発プロセス:1.0版を作る
コンセプト提案
プロダクト提案/ビジネスプラン
開発プラン
開発
最終品質保証
稼働準備
本番稼働
2.4 よくある誤解
まるでウォーターフォールのようだし、それではうまくいかない
全てのステージが平等に重要であるかのように扱われている
どれぐらい時間がかかるのか説明していない
イテレーションはどこにいった?
開発プロセスについて定めていない
各ステージで行うグループ間共同作業のレベルを定めていない
2.5 ビジネスプラン
2.6 プロダクト開発プロセスリリースn.n.nの構築
2.7 プロダクト開発プロセスの補強
段階的な凍結
変更管理プロトコル
リサイクルボックス
2.8 プロダクトマネジメントの重要な概念
マーケテイングの四つのP
有効市場、有効市場規模、マーケットセグメント
受け入れのS字カーフ
ホールプロダクト
技術的優位性と市場優位性
ポジションとポジショニング
ブランド
メインメッセージ
2.9 まとめ
チェックリスト
やってみよう
第3章:マーケテクチャとターキテクチャ
3.1 誰が何に責任を負うのか
3.2 ソリューション開発の初期に現れるフォース
3.3 長期的に稼働しながら短期間で結果を出す
3.4 将来像を示す
3.5 フィードバックを利用する
3.6 はっきりさせる
3.7 一致団結して作業する
合意形成
データに手が届くようにする
3.8 コンテキストダイアグラムと標的プロダクト
3.9 まとめ
チェックリスト
やってみよう
第4章:ビジネスとライセンスモデルの共益関係
4.1 一般的なソフトウェアビジネスモデル
時間ベースのアクセスや利用
トランザクション
メータリングモデル
ハードウェア
サービス
得られた収入/節約できたコスト
4.2 ビ ジネスモデルに関連する権利
4.3 ビジネスモデルに対するターキテクチャのサポート
一般的な課題
時間ベースのアクセスや利用
トランザクション
メータリンク
ハードウェア
4.4 ライセンスモデルを強制する
自己申告制
自家製ライセンスマネージャー
サードパーティのライセンスマネージャーあるいは専用のライセンスマネージャー
クライアント
4.5 マーケットの成熟度がビジネスモデルに与える影響
ビジネスモデルを選択する
4.6 まとめ
チェックリスト
やってみよう
第5章:インライセンステクノロジー
5.1 ライセンス契約のリスクと見返り
5.2 契約一どこで何を約束したのか
契約の基本
ライセンス条項
5.3 ビジネスモデルの衝突、それは交渉の始まり
5.4 ライセンス契約の遵守
5.5 インライセンステクノロジーの管理
5.6 オープンソースライセンス
5.7 ライセンス費用
5.8 ライセンスの収益構造
5.9 まとめ
チェックリスト
やってみよう
第6章:可搬性
6.1 可搬性のもたらす利点
6.2 可搬性に関連するビジネスの事例
6.3 可搬性のあるアプリケーションの構築
インタプリタ言語を使う
標準的な永続化ストレージを使う
業務ロジックを移植可能にする
利用者へ寄り沿うことで失われる可搬性
サブシステム間の相互運用性と標準化のためにXMLを利用する
可搬性の名の下にプラットフオーム固有の能力を埋もれさせてはならない
6.4 苦痛のマトリックス
ステップ1:構成を減らす
ステップ2:組み合わせをランク付けして並び替える
ステップ3:ファイナルカットを決める
6.5 「約束」には用心すること
6.6 まとめ
チェックリスト
やってみよう
第7章:デプロイメントアーキテクチャ
7.1 デプロイメントの選択肢
顧客サイト
アプリケーションサービスプロバイダー
マネージドサービスプロバイダー
トランザクション(Webサービス)
7.2 デプロイメントアーキテクチャにおける顧客の影響力
管理と統合
セキュリティ、プライバシー、ピーク負荷
コストとベンダーヘの信頼
顧客のスキルと経験、地理的な分布
7.3 企業がデプロイメントアーキテクチャに与える影響
セールスサイクル
インフラストラクチャヘの投資
キャッシュフロー
柔軟性
地理的な広がり
価格よリサービス
7.4 ソフトウェアのデプロイメントアーキテクチャを選択する
7.5 デプロイメントアーキテクチャと作業の分担
7.6 情報アプライアンス
7.7 デプロイメントの選択がソフトウェアアーキテクチャに与える影響
柔軟でパラメータ化されている、あるいは、統合の選択肢がない
アップグレードポリシー
データ保護とアクセス
移行手段の選択肢
7.8 一般消費者向けソフトウェアの未来
7.9 まとめ
チェックリスト
やってみよう
第8章:統合と拡張
8.1 顧客をやる気にさせる一原動力
統合/拡張の動機
8.2 レイヤ化ビジネスアーキテクチャ:論理構造
ユーザーインターフェイスレイヤ
サービスレイヤ
ドメインモデルレイヤ
永続化データレイヤ
テーマに応じた変化形
8.3 レイヤ化ビジネスアーキテクチャの構築
8.4 業務ロジックレイヤにおける統合と拡張
テクノロジーと制御ポイント
APIによる統合
レジストレーションによる拡張
8.5 永続データの統合と拡張
ビュー
ユーザー定義フィールト
テーブルフック
表計算ソフトのピボットテーブル
抽出(Extract)、変換(Transform)、読み込み(Load)スクリプト
何が起きているのかを伝えよう
8.6 ビジネスヘの影響
専門サービス部門
研修プログラム
資格認定
ユーザーコミュニティ
使用許諾契約
8.7 複数回のリリースに向けてAPIを管理する
テクニック
8.8 まとめ
チェックリスト
やってみよう
第9章:ブランドとブランド要素
9.1 ブランド要素
名前
見た日、スローガン、その他のブランド要素
トレードマーク(T)記号を使うべきタイミンク
9.2 インライセンスブランドの管理
9.3 ブランド要素のカスタマイス
9.4 ブランド要素の変更
プロダクトの関連要素への影響
変更と品質保証
9.5 まとめ
チェックリスト
やってみよう
第10章:ユーザビリティ
10.1 ユーザビリティはお金になる
10.2 メンタルモデル、メタファー、ユーザビリティ
10.3 ユーザーインターフェイス設計におけるターキテクチャの影響
影響範囲
10.4 スピードの必要性
話している対象をはっきりさせよう
マーケテクトが性能について心から望むこと
ユーザーに応答を返す
性能とターキテクチャ上の影響
10.5 まとめ
チェックリスト
やってみよう
第11章:インストール
11.1 OOBE(Out of box experience)
11.2 痛い!きつと怪我をしたに違いない
顧客が恐れていること
11.3 インストールとアーキテクチャの関係
フォースと選択
11.4 インストールのやり方
インストールのための情報を収集し、事前条件を検証する
インストール
インストール後に確認する
11.5 仕上け
ユーザーはマニュアルを読まない
インストールとアンインストールをテストする
11.6 まとめ
チェックリスト
やってみよう
第12章:アップグレード
12.1 インストールと同じように悪いことしか思い当たらない
アップグレードに伴う恐れ
12.2 アップグレードの苦痛を取り除く
苦痛のないアップグレードのための選択肢
12.3 アップグレードとマーケットの成熟度
12.4 まとめ
チェックリスト
やってみよう
第13章:コンフィギュレーション
13.1 設定可能性一ユーザビリティの一因
13.2 システムの文脈
文脈の情報
13.3 初期化と実行
13.4 値を設定する
13.5 適切な値を設定する
13.6 設定パラメータのヒューリスティクス
13.7 まとめ
チェックリスト
やってみよう
第14章:ログ
14.1 何が起きているか知りたい
14.2 事実だけではない
14.3 ログの書式と管理
ログの書式
ログの管理
ロギングの標準とライブラリ
14.4 ログの後処理
14.5 ロギングサービス
14.6 まとめ
チェックリスト
やってみよう
第15章:リリース管理
15.1 そう、本当に必要なのだ
15.2 ベースラインの確立
15.3 リリース管理
何をリリースするか
対象は誰か
なぜそれが必要か
15.4 リリースの識別子
完全リリース
特別リリース
パッチリリース
バリエーション
15.5 SKUとシリアルナンバー
SKUの管理
シリアルナンバー、レジストレーション、アクティベーション
15.6 ターキテクチャヘの影響
15.7 まとめ
チェックリスト
やってみよう
第16章:セキュリティ
16.1 ウィルス、クラッカー、海賊
リスク管理
見ぎる、言わぎる(無関心を貫く)
16.2 アイデンティティ管理
認可-誰に何ができるのかを定義する
認証一身元を証明する
16.3 トランザクションセキュリティ
監査可能性-行為の証明
一貫性-情報の改ざん、改変を防く
機密性-権限のないものから情報を隔離する
説明性-人々に自分のとった行動の責任を負ってもらう
16.4 ソフトウェアセキュリティ
ソフトウェアセキュリティのテクニック
ソフトウェアセキュリティのコストと恩恵
16.5 情報セキュリティ
16.6 アルゴリズムを秘匿するか、鍵を秘匿するか
16.7 バックドア
16.8 セキュリティとマーケテクチャ
影響のある領域
16.9 まとめ
チェックリスト
やってみよう
補遺A:リリースチェックリスト
プロダクト追跡用の情報
エンジニアリング/開発
品質保証
技術出版物
プロダクトマネジメントの必須事項
知識の移転-専門サービス
知識の移転-販売と販路
知識の移転-テクニカルサポート
リリース活動
補遺B:戦略的プロダクトマネジメントのためのパターン言語
パターンを適用する
結果を表現して共有する
マーケットマッフ
マーケットイベント/マーケットリズム
フィーチャ/利点マッフ
ターキテクチャロードマッフ
参考文献
資料集
訳者あとがき
謝辞
索引