概要
本書は，アプリケーションアーキテクチャの基本設計フェーズにおいて「何を作るか」ではなく「どう作るか」を設計する際のガイドです。心臓部となるサーバサイドを中心に，シングルページアプリケーションの台頭で再び重要性を増してきたクライアントサイド，SQLなどの伝統的な処理方式とビッグデータ技術という新潮流が混在するバッチ処理，システム間連携と，さまざまな分野を網羅します。アーキテクトやエンジニアが習得するべきコアのスキルとして，長きに渡って活用できる一冊です。
こんな方におすすめ
- アーキテクチャのパターンを俯瞰したいアーキテクトやエンジニア
著者から一言
本書のテーマは，アプリケーションアーキテクチャの設計パターンです。アプリケーションアーキテクチャの世界には，すでに偉大な先人たちによって編み出された優れた設計パターンがあります。本書の狙いは，それらの設計パターンをベースに，私がこれまで携わってきた数々のプロジェクトで積み上げてきた設計ノウハウをミックスし，最新のJava EEプラットフォームやフレームワークの仕様を前提に，パターン体系として再整理することにあります。
本書は，エンタープライズアプリケーションの心臓部であるサーバサイドを中心に，シングルページアプリケーションの台頭で再び重要性を増してきたクライアントサイド，SQLなどの伝統的な処理方式とビッグデータ技術という新潮流が混在するバッチ処理，そして昨今「オープンAPI」で改めて注目が集まっているシステム間連携と，様々な分野を広くカバーしています。本書では，すべての分野に渡って語彙や記述レベルを統一し，使用するサンプルも合わせるように工夫しました。たとえば「第10章 非同期呼び出しと並列処理のための設計パターン」と，「第18章 ビッグデータ技術による分散並列バッチ処理」では，「売上取引データを集約する」という同じ例を用いています。これは，同じ例を使うことで，マルチスレッドによる並列処理とビッグデータ技術（Hadoopなど）という2つの異なるアーキテクチャの間に，「大きなデータセットを如何にして効率的に処理するか」という共通の課題があることに気が付きやすくするためです。このように異なる分野におけるアプリケーションアーキテクチャであっても，実は処理の効率化や拡張性の向上など，設計における本質的な課題は同じであることが多いのです。
本書では，「設計パターンのトレードオフ」を特にクローズアップしています。ある1つの機能要件を充足するための設計パターンには，ほとんどの場合，いくつかの選択肢があります。そしてそれらの設計パターン同士には，コスト，技術的な難易度，パフォーマンスなど，様々な観点でトレードオフがあります。本書を通じてこのようなトレードオフを理解すれば，何を基準にどういったパターンを選択するべきか，プロジェクトの中で適切な判断ができるようになるでしょう。
さて，本書のテーマはあくまでも設計パターンですが，各設計パターンを具現化するためのソースコードを，なるべく多めに掲載しています。ウォーターフォール型の開発では，設計フェーズと実装フェーズは分離されますが，設計と実装は「上流と下流」というよりは，相互依存の関係にあると考えるべきです。つまり，実装は「設計ありき」ですが，設計もまた「実装ありき」なのです。アーキテクト自身が実装までを自ら検証して習熟することができれば理想的ですが，現実的には時間の制約などから難しいことが多いでしょう。ただし，自身で実装まですべてをカバーすることはできなくても，「実装のイメージ」を頭の中で描けるようにさえなっていれば，アプリケーションアーキテクチャを設計する上で支障をきたすことはありません。ぜひ読者の皆様には，最適な設計のために，本書に掲載されたソースコードを読み解くことによって，実装をイメージできる力を養っていただきたいと考えています。
エンタープライズシステムは，これからクラウドへの移行がますます進むものと思いますが，過去の資産も含めると，まだまだオンプレミスの比率が相応に高い状況です。しかし，クラウドであろうとオンプレミスであろうと，アプリケーションアーキテクチャの根幹部分は大きくは変わりません。本書で取り扱っているアプリケーションアーキテクチャの設計は，今後エンタープライズシステムを取り巻く環境が移り変わっても，「ぶれる」ことの少ない普遍性の高いテーマです。アーキテクトが習得するべきコアのスキルとして，長きに渡って活用することができるでしょう。
本書が，読者の皆様が担当するエンタープライズシステムにおいて，アプリケーションアーキテクチャ設計の一助となれば幸いです。
（本書「はじめに」より）
サポート
ダウンロード
以下のサイトより，本書サンプルコードをダウンロードしてご入手ください（順次更新中）。
（2017年10月16日更新）
サーバサイド，システム間連携（Part2，5）
https://github.com/KenyaSaitoh/book_ap_archi_repo
※Eclipseプロジェクトとしての公開
クライアントサイド（Part3）
https://github.com/KenyaSaitoh/book_ap_archi_client_repo
ハッチ処理（Part4）
https://github.com/KenyaSaitoh/book_ap_archi_batch_repo
正誤表
本書の以下の部分に誤りがありました。ここに訂正するとともに，ご迷惑をおかけしたことを深くお詫び申し上げます。
（2018年5月28日最終更新）
P.487 本文、下から3行目（①の2行目内）
| 誤 |
存在しない場合は挿入するに、ロジックを構築する
|
|---|
| 正 |
存在しない場合は挿入するように、ロジックを構築する
|
|---|
（以下2017年11月30日更新）
P.47 「リクエストスコープ」「セッションスコープ」「アプリケーションスコープ」の各サンプルコード内の最終行（計3ヵ所）
| 誤 |
Foo foo = (Foo)～.setAttribute("foo");
|
|---|
| 正 |
Foo foo = (Foo)～.getAttribute("foo");
|
|---|
（以下2017年11月1日更新）
P.38 本文，下から2行目
| 誤 |
Red Hat社の「WildFly」
|
|---|
| 正 |
JBossコミュニティが開発するOSSの「WildFly」
|
|---|
（以下2017年10月16日更新）
P.269，本文，下から3行目
| 誤 | APIによってクライテリアはAPIによって～
|
|---|
| 正 | クライテリアはAPIによって～
|
|---|
P.316，コード11-1の15行目
| 誤 |
|
|---|
| 正 |
byte[] buf = new byte[50];
|
|---|
P.318，ページ下のコード内，14行目
| 誤 |
|
|---|
| 正 |
byte[] buf = new byte[50];
|
|---|
P.321，ページ1番上のコード内，2行目
| 誤 |
"SELECT FILE_ID, FILE_NAME FROM FILE_STORE WHERE FILE_ID = ?");
|
|---|
| 正 |
"SELECT FILE_NAME, CONTENT_TYPE FROM FILE_STORE WHERE FILE_ID = ?");
|
|---|
P.321，ページ1番下のコード内，5～8行目
| 誤 |
response.setContentType(contentType);
bis = new BufferedInputStream(is); // isは入力ストリーム
sos = response.getOutputStream();
byte[] buf = new byte50;
|
|---|
| 正 |
response.setContentType(contentType);
try {
bis = new BufferedInputStream(is); // isは入力ストリーム
sos = response.getOutputStream();
byte[] buf = new byte[50];
|
|---|
P.429，本文，上から3行目
| 誤 | 先頭の1件（ステータスは"未処理"）
|
|---|
| 正 | 先頭の1件（ステータスは"処理未済"）
|
|---|
（以下，2017年10月12日更新）
P.16，目次，16.2節見出し
| 誤 |
16.2 バッチ処理（オンラインバッチ）の設計パターン
|
|---|
| 正 |
16.2 バッチ処理（オフラインバッチ）の設計パターン
|
|---|
P.62，図4-6のキャプション
| 誤 |
図4-6 空サブミット自動サブミット方式
|
|---|
| 正 |
図4-6 空ページ自動サブミット方式
|
|---|
P.91，図4-18
| 誤 |
|
|---|
| 正 |
|
|---|
P.101，本文下から4行
| 誤 |
もし当該ユーザがすでに別のクライアント端末でログイン済みの場合（ログインテーブルに当該ユーザのデータが存在しセッションIDが異なる）は、通常は後勝ちとし、ログインテーブル上でセッションIDを上書きします。そして先にログインしていたクライアント端末のセッション変数を無効化し、強制的にログアウトさせます
|
|---|
| 正 |
あるクライアント端末からログインがあったときに、当該ユーザがすでに別の端末でログインしていた場合（ログインテーブルに当該ユーザのデータが存在しセッションIDが異なる）、通常は後勝ちとし、ログインテーブルの当該ユーザのデータを新しいセッションIDで上書きします。先にログインしていた端末では、後続のリクエストのチェックにおいてセッションIDが不一致になるため、セッション変数を無効化し、ログアウトします
|
|---|
P.249，図8-16
| 誤 |
|
|---|
| 正 |
|
|---|
P.264，本文下から2行
| 誤 |
指定した結果クラス（ここではEntityResultクラス）に結果が格納されて返されます4。以下に、結果クラス（EntityResultクラス）のコードを示します。
|
|---|
| 正 |
指定した結果クラス（ここではEmployeeResultクラス）に結果が格納されて返されます4。以下に、結果クラス（EmployeeResultクラス）のコードを示します。
|
|---|
P.265，コード8-6のキャプション
| 誤 |
コード8-6 結果クラス（EntityResult）
|
|---|
| 正 |
コード8-6 結果クラス（EmployeeResult）
|
|---|
P.401，16.2節見出し
| 誤 |
16.2 バッチ処理（オンラインバッチ）の設計パターン
|
|---|
| 正 |
16.2 バッチ処理（オフラインバッチ）の設計パターン
|
|---|
