いまでは、どの企業にも情報システムが導入されていまが、その構造は複雑化しているのが現状です。このような複雑なシステムをスムーズに稼動させるには、目的に応じて最適なアーキテクチャを設計する必要があります。ここでアーキテクトにとって必要なのは“有望な技術を見抜く目”です。つまり、技術の使い方ではなくどの技術を使うかがアーキテクトの腕の見せどころというわけです。本書では、この目を養うためにシステム設計にまつわるさまざまな考え方を解説しています。
本書はDBマガジンの人気連載「アーキテクトの審美眼」(全15回)に加筆/修正を加え、一冊にまとめたものです。
1 アーキテクチャとは何か
例えばイベント駆動を考える
アーキテクチャの構造の原則
アーキテクチャの縦と横の関係
縦横2つに分ける理由と効果
縦と横で表現したアーキテクチャの例
もう一度世の中の動きを見る
2 俊敏なアーキテクチャ
システムを俯瞰する視点「俊敏さ」
抽象化を支えるボトムアップ
俊敏なアーキテクチャの構築法
(1)ITシステム間の接続
(2)データ品質の確保
(3)ビジネスプロセスの最適化
(4)ビジネスの観測可能性の実現
(5)ビジネスの制御可能性の実現
(6)情報一元化の達成
俊敏さをさらに理解する
成熟度モデル
成熟度モデルの例
典型的なロードマップ
現実との乖離
要求の合意に基づかないシステム開発
ドメイン駆動型開発
技術に対する姿勢の大切さ
3 概念レベルの分類法から見たアーキテクチャ(基礎編)
ソフトウェア開発の基本は分類と複合化
ソフトウェア開発における分類法
もの/こと分析
「もの」と「こと」の関係を分析する
「もの」「こと」からビジネス状況を分析する
「もの」の見え方の変化をとらえる
オブジェクト指向言語の継承による分類とその限界
分類法はスナップショット
もの/ことの分析のまとめ
概念レベルの分類法から見たアーキテクチャ(応用編)
概念レベルの位置付けを振り返る
概念モデルからの分析/設計方法
アプローチによる分析方法の違い
オブジェクト指向アプローチの分析方法
データ中心アプローチの分析方法
ステレオタイプによる分類
ストリームラインオブジェクトモデリングによる分析/設計
分析の練習
概念レベルの最新動向
(1)Webサービスの高度化
(2)概念スキーマ層
概念レベルの分類法の今後
5 アーキテクチャ構築におけるモデル分割法
概念モデルの分割
分割基準の客観性の問題
データモデルの分割基準の客観性を考察する
オブジェクト指向での客観的分割が困難なワケ
責務の配置について考える
責務の配置とは
なぜ責務の配置が客観的分割を困難にするのか
トップダウン分析を行ううえで重要なこと
アーキテクチャ定義の基本原則を守る
分割目的の多様性問題を解消する関心分離の原則
関心は複数あるのが悩みどころ
分割の目的はどう決めるべきか
アーキテクチャの管理と進化
6 要件の定義と設計モデルに基づく開発法
要求の定義法の客観性
ユースケースを利用した要求定義とは
ユースケースで客観的な要求定義とは可能か
ユースケースによる要件定義の課題
要求追跡性の重要さ
ソフトウェア開発法の現状と課題
手続き型による開発法
手続き型の欠点
設計モデルに基づく開発法
設計モデルの利点
まだ可能性を活かしきれていない設計モデル
7 アーキテクチャの基本構造
“WHY”に基づくアーキテクチャの構造
要件の多次元性
要件の多次元性の詳細に迫る
オブジェクト指向における概念モデルの分類法の実現
ソフトウェアの内部構造
縦の構造の構築化
縦の構造の構築例
実装クラスの多重継承の問題
インターフェイスの多重継承
縦の構造の単純化
オブジェクト指向言語のクラスの限界
アーキテクチャの構築に“WHY”が重要なワケ
段階的拡張のためのレイヤー構造
段階的に拡張可能な構造の作り方
段階的に拡張可能なアーキテクチャの例
変化に強く、段階的に拡張可能なアーキテクチャを構築するには
8 アーキテクチャの構造変更の基本方針
オブジェクト指向の利点を生む責務の配置の原則
オブジェクト指向の欠点―散乱ともつれ合い
散乱ともつれ合いの解消法
要求の変更と保守の単位を両立は困難
クラスによる保守の単位から変更への単位を分離する
(1)アスペクト指向
(2)サブジェクト指向
アスペクト指向による変化への対処法
アスペクト指向の弱点
サブジェクト指向による変化への対応法
アスペクト指向とサブジェクト指向の組み合わせ
モデルの対称性
変化と複雑さに対応し、単純で美しいアーキテクチャを目指して
9 スケーラブルなアーキテクチャ
スケーラビリティの要因
データアーキテクチャを決める4つの技術要因
水平分割
垂直分割
概念レベルの「もの/こと分析」によるスケーラビリティを決める
「もの/こと分析」によるスケーラビリティの決め方
データの種別ごとの適用技術一覧
データモデルのパーティション分割の具体例
企業システムのデータの配置とデータアーキテクチャ
アプリケーションの変更コスト
アプリケーションアーキテクチャの実現方法
データモデルを基準としたアプリケーションの配置方法
オブジェクト指向言語と、フレームワークやミドルウェアの棲み分け
スケーラブルなアーキテクチャの構築手順
10 契約による品質と生産性の改善
契約とは
サービス指向における契約
操作や属性のインターフェイス定義では不十分なワケ
オブジェクト指向での契約定義の例
(1)クラスの継承関係に基づく不変条件
(2)要素オブジェクトに基づく不変条件
(3)参照や呼び出し先オブジェクトに基づく不変条件
開発言語の役割
そのほかの契約定義
オブジェクト指向の責務における契約の役割
ソフトウェアテスト手法における契約の役割
サービス指向の疎結合における契約の役割
特性という契約
特性に基づく開発プロセス
広がる契約の利用
11 ビジネスとITとのギャップを埋めるドメインモデル
手続き型か、オブジェクト指向か
プロセスロジック資産化の時代
データ中心アプローチとは
データ定義による保守性の限界
手続き型とオブジェクト指向による設計の違い
手続き型とオブジェクト指向による設計の特徴
手続き型による設計の特徴
オブジェクト指向による設計の特徴
ドメインモデル設計の注意点
ドメインモデル設計における二つの問題とその対応
サービスレイヤー導入による問題
(1)サービスレイヤーと、別の共通機能パターン化との分担
(2)サービスレイヤーとドメインモデルの振る舞いの分担
ドメインモデル貧血症発生の要因
フレームワーク/プラットフォームに依存させずにドメインモデルを実現する
要因インターフェイスの進化
横断的な関心の実現性の進化
ドメイン駆動型設計
ビジネスとITのギャップを埋める模索は続く
12 ソフトウェア開発パラダイム進化から見たアーキテクチャ設計
発展的なアーキテクチャを目指すために
オブジェクト指向言語の登場と限界
コンポーネントの登場
論理レベルモデルの台頭
サービス指向の登場
階層型アーキテクチャに限定されない選択肢
ソフトウェア開発における分割法
サービス指向におけるアプリケーションアーキテクチャ
抽象化されるアーキテクチャ設計
階層型アーキテクチャの合理性
Web指向アーキテクチャのパラダイム
オブジェクト指向とWebのアプローチ
Web指向アーキテクチャとは
13 オブジェクト指向の進化は止まったのか?
オブジェクト指向の適用領域の変遷
サブシステム間の連携での適用
現在のオブジェクト指向の適用領域
オブジェクト指向のクラス定義を補足するコンポーネントの登場
オブジェクト指向の適用方法の変遷
保守の単位
再利用の単位
インスタンス生成による実行
オブジェクト指向の表現能力の適切さ
オブジェクト指向の開発プロセスにおける適切さ
開発プロセスはミクロ的に考える
オブジェクト指向のソフトウェア開発の複雑さへの対応能力
オブジェクト指向の進化の方向性
14 アーキテクトの指向パターン
ソフトウェア開発パターンとアーキテクト
ソフトウェア開発パターンの有効性
問題駆動と解決駆動
問題駆動と解決駆動を組み合わせる
思考パターンとは
(1)非属人的、科学的パターン
離散性とは
多次元性
直交性
線形成
対称性
非予見性
非属人的、科学的パターンのまとめ
(3)有効性を持つプラクティス
分割の思考パターン~フェルミ推定
分析設計は分割の思考パターン
代表的な分割法の原則
(1)意味と表現の分離
(2)コンテンツとスキーマーの分離
(3)マスタデータの分離
(4)プロセスの分離
(5)コントラクト、ポリシー、ルールの分離
(6)プロセスと手順の分離
プラクティスの適用に現れる代表的な対立
(1)長期と短期
(2)全体と個別
(3)自由と強制
(4)集中と分散
(5)結果とプロセス
(2)思考の推移パターン
(1)俯瞰的な思考
(2)結論から考える仮設検証
(3)単純化のための抽象化
kwy8791 さん
2011-12-22
ソフトウェアアーキテクチャについての本なんだけど…。知識が足りず、ほとんど理解できなかった…。後日再読必須な一冊
kozawa さん
2009-11-18
悪い本じゃあないけど一人でざっと読んでも。。。識者含めて輪読しつつ議論すると深まりそうだけど。