目次

表紙
本書情報および正誤表のWebページ
序文
はじめに
訳者まえがき
第1章　保守容易性
1.1　保守容易性とは？
1.2　保守容易性によって実装可能になる機能
1.3　保守のしやすさによって向上する開発者満足度
1.4　保守容易性によって結果が変わる意思決定
1.5　保守容易性の維持
第2章　従来の多層アーキテクチャの何が問題なのか？
2.1　データベース中心の設計になってしまう問題
2.2　問題のある短絡的な実装になってしまう問題
2.3　テストがしづらくなる問題
2.4　ユースケースが見つけづらくなる問題
2.5　異なる作業を同時に行なうことが難しくなる問題
2.6 この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第3章　依存関係の逆転
3.1　単一責任の原則
3.2　変更による影響に関する事例
3.3　依存関係逆転の原則
3.4　クリーンなアーキテクチャ
3.5　ヘキサゴナルアーキテクチャ
訳者・補足 >>> 本書の考え方
3.6　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第4章　パッケージ構成に関する戦略
4.1　層を意識したパッケージ構成
4.2　機能を意識したパッケージ構成
4.3　アーキテクチャの構成要素を意識したパッケージ構成
4.4　依存注入（DI）の役割
4.5　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第5章　ユースケースの実装
5.1　ドメインモデルの実装
5.2　ユースケースの概要
5.3　入力値の妥当性確認
5.4　コンストラクタの活用
5.5　ユースケースと入力モデル
5.6　ビジネスルールに関する妥当性確認
5.7　濃いドメインモデル vs. 薄いドメインモデル
5.8　ユースケースごとに異なる出力モデル
5.9　読み込みしか行なわないユースケースの場合
5.10　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第6章　Webアダプタの実装
6.1　依存関係の逆転
6.2　Webアダプタの責務
6.3　コントローラの分割
6.4　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第7章　永続化アダプタの実装
7.1　依存関係の逆転
7.2　永続化アダプタの責務
7.3　ポートの分割
7.4　永続化アダプタの分割
7.5　Spring Data JPAを用いたサンプル
7.6　データベーストランザクション
7.7　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第8章　アーキテクチャの構成要素に対するテスト
8.1　テストピラミッド
8.2　ドメインエンティティの検証：単体テスト
8.3　ユースケースの検証：単体テスト
8.4　Webアダプタの検証：統合テスト
8.5　永続化アダプタの検証：統合テスト
8.6　主要なシナリオの検証：システムテスト
8.7　どのくらいテストをすれば十分なのか？
8.8　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第9章　境界を越える際のモデルの変換
9.1　「モデルを変換しない」という戦略
9.2　双方向でのモデルの変換
9.3　徹底的なモデルの変換
9.4　一方向でのモデルの変換
9.5　モデルの変換に関して、どの戦略をいつ使うべきなのか？
9.6　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第10章　アプリケーションの組み立て
10.1　アプリケーションをどのように組み立てるのかをなぜ考慮しなくてはならないのか？
10.2　標準的なJava のコードだけを用いたアプリケーションの組み立て
10.3　コンポーネントスキャンを用いたアプリケーションの組み立て
10.4　Java Configを用いたアプリケーションの組み立て
10.5　この章がどのように保守のしやすいソフトウェアを組み立てる際の助けとなるのか？
第11章　短絡的な実装への意図した選択
11.1　ソフトウェア開発における短絡的な実装と割れ窓理論の類似点
11.2　クリーンな状態で開発を始めることの重要性
11.3　ユースケース間でのモデルの共有
11.4　入力モデルもしくは出力モデルとしてのドメインエンティティの使用
11.5　受信ポートの省略
11.6　サービスの省略
11.7　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第12章　アーキテクチャ内の境界の維持
12.1　境界と依存
12.2　アクセス修飾子を用いた境界の維持
12.3　適応度関数の活用：コンパイル後の検証
12.4　成果物の分割
12.5　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第13章　複数の境界づけられたコンテキストの管理
13.1　境界づけられたコンテキストごとに1つのアプリケーションの核を用いる場合
13.2　各境界づけられたコンテキストの分離
13.3　境界づけられたコンテキスト同士の適切な連携
13.4　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第14章　コンポーネント基盤のアーキテクチャ
14.1　コンポーネントの抽出と抽出したコンポーネント同士の連携
14.2　事例：「検証エンジン（check engine）」コンポーネントの構築
14.3　コンポーネント間の境界の強制
14.4　この章がどのように保守のしやすいソフトウェアを構築する際の助けとなるのか？
第15章　アーキテクチャの決定
15.1　最初はシンプルに
15.2　ドメインの進化
15.3　自身の経験への信頼
15.4　結論
索引
著者紹介・訳者紹介
奥付

著者プロフィール

• Tom Hombergs（著者）

  ■著者
  ●Tom Hombergs（トム・ホンベルグス）
  ソフトウェアエンジニアであり、著者であり、ものごとをシンプルにすることに情熱を持っている人。複雑さは彼にとってのクリプトナイト（スーパーマンが弱点としている物質）であるため、複雑さをいかにシンプルなものに分解して理解するのかについて日々汗を流している。そして、もし、可能なかぎりシンプルにすることができれば、誰もがその複雑さを理解することができるようになるとも考えている。そのため、シンプルなコードを書くのと同じくらいシンプルで読みやすい文章、記事、書籍に加え、開発者向けの資料を書いている。現在、オーストラリアのシドニーにあるAtlassian社で働いており、Atlassian社の他の開発者が使用する技術スタックの開発者体験（Developer Experience：DX）を高める責務を担っている。
  イナビ出版、2022年）がある。

• 須田 智之（翻訳）

  ■訳者
  ●須田智之（すだ ともゆき）
  15年近くいくつかのSI企業の社員として働いたのちに独立。最近の邦訳書には『セキュア・バイ・デザイン　安全なソフトウェア設計』（マイナビ出版、2021年）、『単体テストの考え方/使い方』（マ