実践！ソフトウェアアーキテクチャ

2014-04-24 22:50:14

技術評論社の書籍ページ

第1章　ソフトウェアアーキテクチャとは？

1-1　ソフトウェアアーキテクトとは？

1-1-1　ウォーターフォールの “キャリアパス” には問題がある

1-1-2　プログラマの生産性には，大きな差がある

1-1-3　プログラマからソフトウェアアーキテクトというキャリアパス

1-2　ソフトウェアアーキテクチャとは？

1-2-1　ビジネスアプリケーションでは，標準化が有効である

1-2-2　まずは，クラスライブラリを作る

1-2-3　そして，クラスライブラリを呼び出す部分も作る

●コラム　アスペクト指向プログラミングは使わないの？

1-3　補講：プログラミングを知らない設計者による設計のやり方

1-3-1　RDBMS以前。COBOLな人が処理に注目しがちな理由

1-3-2　ER図。各論に入らずに全体像を作成する

1-3-3　Table Moduleパターン。重複のない形に機能を構造化する

第2章　サンプルアプリケーションの仕様

2-1　ER図

2-2　スマートクライアント

2-3　Webアプリケーション

2-4　セットアップの方法

第3章　アプリケーションの全体構造

3-1　Layersアーキテクチャパターン

3-1-1　アセンブリのレベルでカプセル化

3-1-2　重ねて積んで，下のレイヤをカプセル化

3-1-3　レイヤに意味を持たせて標準化しましょう

3-2　Patterns＆Practicesでの全体構造

3-3　本書におけるビジネス・アプリケーションの全体構造

3-3-1　不満点1：エンタープライズの視点が足りない

3-3-2　不満点2：サービスエージェントは処理にも使える

3-3-3　不満点3：ビジネスエンティティはデータレイヤ

3-3-4　不満点4：ユーザインターフェイスプロセスはなんだか胡散臭い

3-3-5　本書におけるビジネスアプリケーションの全体構造

第4章　ビジネスエンティティ

4-1　型付DateSetって便利

4-1-1　思考実験：SQLを発行する “だけの” アプリケーション

4-1-2　ビジネスエンティティが必要な理由

4-1-3　プレゼンテーションまでと考えると，型付DateSetが便利

4-2　オブジェクト指向しゃなくていいの？

4-3　型付DateSetを用いたビジネスエンティティ

4-3-1　ソリューションとプロジェクトの作成

4-3-2　RDBMSのスキーマを作成

4-3-3　型付DateSetの作成

4-3-4　プロパティとメソッドの追加

第5章　データアクセスロジックコンポーネント

5-1　JOINする？しない？

5-1-1　表を編集するとなると…

5-1-2　テーブル単位で取得する

5-1-3　JOIN演算の説明

5-2　関係するテーブルを正しく巡り，サイクルデッドロックが発生しないように更新する

5-2-1　クラスライブラリを作成してみる

●コラム　CallFillTableAdapters()メソッドを実装できた理由

●コラム　イテレータは非常に便利

5-2-2　更新する場合を考える

5-2-3　追加／削除の場合を考える

5-2-4　サイクルデッドロックを防ぐ

●コラム　サイクルデッドロックとは？

●コラム　Table Moduleパターンはどうなった？

5-2-5　ロストアップデートを防ぐ

5-3　TableAdapterを用いたデータアクセスロジックコンポーネント

5-3-1　TableAdapterの作成

5-3-2　Taillsland.RX的なTableAdapterの呼び出し

5-3-3　特殊ケースへの対応

第6章　ビジネスコンポーネント

6-1　Table Moduleで設計者と良い関係を築きましょう

6-1-1　設計者とは，ビジネスの専門家である

6-1-2　ransaction ScriptとDomain ModelとTable Module

6-1-3　Table Moduleなら，設計者にプログラミングの知識は不要となる

6-2　トランザクション管理を考える前に…

6-2-1　アシッドトランザクション

6-2-2　ショートトランザクションとロングトランザクション

6-3　TransactionScopeでReadCommittedなショートトランザクション

6-3-1　トランザクション管理方式はTransactionScope

6-3-2　IsolationレベルはReadCommitted

6-4　作りこみによるロングトランザクション

6-4-1　競合が発生する場合は，排他ロジックを作りこむ

6-4-2　補償トランザクションを作成する

6-5　ステート管理とロギングとエラーと主キー設定

6-5-1　ステート管理

6-5-2　ロギング

6-5-3　エラー

6-5-4　主キーの設定

6-6　ビジネスコンポーネントの作り方

6-6-1　ソリューションにTaillsland.RXを追加

6-6-2　共通メソッドの作り方

6-6-3　独自メソッドの作り方

6-6-4　Validatorの作り方

第7章　ユニットテスト

7-1　テスト駆動開発

7-1-1　テストの自動化

7-1-2　リファクタリング

7-2　自動テストの対象

7-2-1　プレゼンテーションレイヤは自動テストしない

●コラム　テスト騒動開発の落とし穴

7-2-2　プレゼンテーションレイヤは自動テストしない

7-2-3　RDBMSを使ってテストしちゃえ

7-3　ユニットテストの作り方

7-3-1　テストプロジェクトを追加

7-3-2　データベースプロジェクトを追加し，初期化スクリプトを登録

7-3-3　ユニットテストの一般論

7-3-4　ユニットテストを作成

●コラム　privateメソッドに対するユニットテスト

第8章　サービスインターフェイスとサービスエージェント

8-1　XML Webサービス

8-1-1　XMLを使用したメッセージ交換

8-1-2　XML Webサービスを採用する理由

8-1-3　通信の粒度に関する推奨事項

8-2　サービスインターフェイスの作り方

8-2-1　XML Webサービスの作り方の一般論

8-2-2　エラー処理

8-2-3　性能を劣化させないための安全弁の取り組み

8-3　サービスエージェントの作り方

8-3-1　wsdl.exeを実行してスタブを作成

8-3-2　データベースプロジェクトを追加し，初期化スクリプトを登録

8-3-3　クライアントのValidatorを作成，サーバのValidatorを修正

第9章　プレゼンテーションレイヤ（スマートクライアント）

9-1　画面はテーブルを元に設計しましょう

9-1-1　ER図から画面設計への変換指数

9-1-2　正規化って素晴らしい

9-1-3　ルールは破るためにあるけれど，高くつくことが多いので注意

9-2　データバインディングでソースコードを激減させましょう

9-2-1　表のデータバインディング

9-2-2　表のデータバインディング

9-2-3　子テーブルのデータバインディング

9-3　Taillsland.RXでのデータバインディング

9-3-1　データソースにサービスエージェントの型付DataSetを追加する方法

9-3-2　XML Webサービスの呼び出しには注意が必要

9-3-3　カラムのエラーはErrorProvider，レコードのエラーはダイアログ

9-3-4　画面遷移にまつわるエトセトラ

9-3-5　行の削除では，子テーブルの行も削除する

9-3-6　コントロールに入力可能な長さを設定

9-3-7　イベントハンドラでは，例外をハンドリンクする

9-4　スマートクライアントの作り方

9-4-1　プロジェクトの追加

9-4-2　表形式のフォームの作り方

●コラム　リレーショナルデータベースを更新する単位

第10章　プレゼンテーションレイヤ（Webアプリケーション編）

10-1　Webアプリケーションよりスマートクライアントの方が好き

10-1-1　イントラネットなら，漸近的なユーザビリティ向上で楽ちん

10-1-2　イントラネットのアプリケーションはどっちが良い？

実践！ソフトウェアアーキテクチャ

2014-04-24 22:50:14

第1章 ソフトウェアアーキテクチャとは？

1-1 ソフトウェアアーキテクトとは？

1-1-1 ウォーター フォールの “キャリア パス” には問題がある

1-1-2 プログラマの生産性には，大きな差がある

1-1-3 プログラマからソフトウェアアーキテクトというキャリア パス

1-2 ソフトウェアアーキテクチャとは？

1-2-1 ビジネス アプリケーションでは，標準化が有効である

1-2-2 まずは，クラス ライブラリを作る

1-2-3 そして，クラス ライブラリを呼び出す部分も作る

●コラム アスペクト指向プログラミングは使わないの？

1-3 補講：プログラミングを知らない設計者による設計のやり方

1-3-1 RDBMS以前。COBOLな人が処理に注目しがちな理由

1-3-2 ER図。各論に入らずに全体像を作成する

1-3-3 Table Moduleパターン。重複のない形に機能を構造化する

第2章 サンプルアプリケーションの仕様

2-1 ER図

2-2 スマート クライアント

2-3 Webアプリケーション

2-4 セットアップの方法

第3章 アプリケーションの全体構造

3-1 Layersアーキテクチャ パターン

3-1-1 アセンブリのレベルでカプセル化

3-1-2 重ねて積んで，下のレイヤをカプセル化

3-1-3 レイヤに意味を持たせて標準化しましょう

3-2 Patterns＆Practicesでの全体構造

3-3 本書におけるビジネス・アプリケーションの全体構造

3-3-1 不満点1：エンタープライズの視点が足りない

3-3-2 不満点2：サービス エージェントは処理にも使える

3-3-3 不満点3：ビジネス エンティティはデータ レイヤ

3-3-4 不満点4：ユーザ インターフェイス プロセスはなんだか胡散臭い

3-3-5 本書におけるビジネス アプリケーションの全体構造

第4章 ビジネス エンティティ

4-1 型付DateSetって便利

4-1-1 思考実験：SQLを発行する “だけの” アプリケーション

4-1-2 ビジネス エンティティが必要な理由

4-1-3 プレゼンテーションまでと考えると，型付DateSetが便利

4-2 オブジェクト指向しゃなくていいの？

4-3 型付DateSetを用いたビジネス エンティティ

4-3-1 ソリューションとプロジェクトの作成

4-3-2 RDBMSのスキーマを作成

4-3-3 型付DateSetの作成

4-3-4 プロパティとメソッドの追加

第5章 データ アクセス ロジック コンポーネント

5-1 JOINする？しない？

5-1-1 表を編集するとなると…

5-1-2 テーブル単位で取得する

5-1-3 JOIN演算の説明

5-2 関係するテーブルを正しく巡り，サイクルデッドロックが発生しないように更新する

5-2-1 クラス ライブラリを作成してみる

●コラム CallFillTableAdapters()メソッドを実装できた理由

●コラム イテレータは非常に便利

5-2-2 更新する場合を考える

5-2-3 追加／削除の場合を考える

5-2-4 サイクル デッド ロックを防ぐ

●コラム サイクル デッド ロックとは？

●コラム Table Moduleパターンはどうなった？

5-2-5 ロスト アップデートを防ぐ

5-3 TableAdapterを用いたデータアクセス ロジック コンポーネント

5-3-1 TableAdapterの作成

5-3-2 Taillsland.RX的なTableAdapterの呼び出し

5-3-3 特殊ケースへの対応

第6章 ビジネスコンポーネント

6-1 Table Moduleで設計者と良い関係を築きましょう

6-1-1 設計者とは，ビジネスの専門家である

6-1-2 ransaction ScriptとDomain ModelとTable Module

6-1-3 Table Moduleなら，設計者にプログラミングの知識は不要となる

6-2 トランザクション管理を考える前に…

6-2-1 アシッドトランザクション

6-2-2 ショートトランザクションとロング トランザクション

6-3 TransactionScopeでReadCommittedなショート トランザクション

6-3-1 トランザクション管理方式はTransactionScope

6-3-2 IsolationレベルはReadCommitted

6-4 作りこみによるロングトランザクション

6-4-1 競合が発生する場合は，排他ロジックを作りこむ

6-4-2 補償トランザクションを作成する

6-5 ステート管理とロギングとエラーと主キー設定

6-5-1 ステート管理

6-5-2 ロギング

第1章　ソフトウェアアーキテクチャとは？

1-1　ソフトウェアアーキテクトとは？

1-1-1　ウォーターフォールの “キャリアパス” には問題がある

1-1-2　プログラマの生産性には，大きな差がある

1-1-3　プログラマからソフトウェアアーキテクトというキャリアパス

1-2　ソフトウェアアーキテクチャとは？

1-2-1　ビジネスアプリケーションでは，標準化が有効である

1-2-2　まずは，クラスライブラリを作る

1-2-3　そして，クラスライブラリを呼び出す部分も作る

●コラム　アスペクト指向プログラミングは使わないの？

1-3　補講：プログラミングを知らない設計者による設計のやり方

1-3-1　RDBMS以前。COBOLな人が処理に注目しがちな理由

1-3-2　ER図。各論に入らずに全体像を作成する

1-3-3　Table Moduleパターン。重複のない形に機能を構造化する

第2章　サンプルアプリケーションの仕様

2-1　ER図

2-2　スマートクライアント

2-3　Webアプリケーション

2-4　セットアップの方法

第3章　アプリケーションの全体構造

3-1　Layersアーキテクチャパターン

3-1-1　アセンブリのレベルでカプセル化

3-1-2　重ねて積んで，下のレイヤをカプセル化

3-1-3　レイヤに意味を持たせて標準化しましょう

3-2　Patterns＆Practicesでの全体構造

3-3　本書におけるビジネス・アプリケーションの全体構造

3-3-1　不満点1：エンタープライズの視点が足りない

3-3-2　不満点2：サービスエージェントは処理にも使える

3-3-3　不満点3：ビジネスエンティティはデータレイヤ

3-3-4　不満点4：ユーザインターフェイスプロセスはなんだか胡散臭い

3-3-5　本書におけるビジネスアプリケーションの全体構造

第4章　ビジネスエンティティ

4-1　型付DateSetって便利

4-1-1　思考実験：SQLを発行する “だけの” アプリケーション

4-1-2　ビジネスエンティティが必要な理由

4-1-3　プレゼンテーションまでと考えると，型付DateSetが便利

4-2　オブジェクト指向しゃなくていいの？

4-3　型付DateSetを用いたビジネスエンティティ

4-3-1　ソリューションとプロジェクトの作成

4-3-2　RDBMSのスキーマを作成

4-3-3　型付DateSetの作成

4-3-4　プロパティとメソッドの追加

第5章　データアクセスロジックコンポーネント

5-1　JOINする？しない？

5-1-1　表を編集するとなると…

5-1-2　テーブル単位で取得する

5-1-3　JOIN演算の説明

5-2　関係するテーブルを正しく巡り，サイクルデッドロックが発生しないように更新する

5-2-1　クラスライブラリを作成してみる

●コラム　CallFillTableAdapters()メソッドを実装できた理由

●コラム　イテレータは非常に便利

5-2-2　更新する場合を考える

5-2-3　追加／削除の場合を考える

5-2-4　サイクルデッドロックを防ぐ

●コラム　サイクルデッドロックとは？

●コラム　Table Moduleパターンはどうなった？

5-2-5　ロストアップデートを防ぐ

5-3　TableAdapterを用いたデータアクセスロジックコンポーネント

5-3-1　TableAdapterの作成

5-3-2　Taillsland.RX的なTableAdapterの呼び出し

5-3-3　特殊ケースへの対応

第6章　ビジネスコンポーネント

6-1　Table Moduleで設計者と良い関係を築きましょう

6-1-1　設計者とは，ビジネスの専門家である

6-1-2　ransaction ScriptとDomain ModelとTable Module

6-1-3　Table Moduleなら，設計者にプログラミングの知識は不要となる

6-2　トランザクション管理を考える前に…

6-2-1　アシッドトランザクション

6-2-2　ショートトランザクションとロングトランザクション

6-3　TransactionScopeでReadCommittedなショートトランザクション

6-3-1　トランザクション管理方式はTransactionScope

6-3-2　IsolationレベルはReadCommitted

6-4　作りこみによるロングトランザクション

6-4-1　競合が発生する場合は，排他ロジックを作りこむ

6-4-2　補償トランザクションを作成する

6-5　ステート管理とロギングとエラーと主キー設定

6-5-1　ステート管理

6-5-2　ロギング

6-5-3　エラー

6-5-4　主キーの設定