購入前に目次をご確認ください

インプレス[コンピュータ・IT]ムック 手を動かしてわかるクリーンアーキテクチャ

インプレス / 2024年07月19日 / 全287ページ

Robert C. Martin氏が提唱するソフトウェア設計パターン「クリーンアーキテクチャ」の概念に沿って、Webアプリケーションを構築するにはどうするのか、について実装コードとともに解説。ソフトウェア設計に興味を持っている開発者の方、クリーンアーキテクチャとその実装方法を知りたい開発者の方におすすめの一冊。

目次

  • 本書情報および正誤表の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 変更による影響に関する事例
  • 本書情報および正誤表の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 結論
  • 索引
  • 著者紹介・訳者紹介
  • 奥付

※このデジタル雑誌には目次に記載されているコンテンツが含まれています。それ以外のコンテンツは、本誌のコンテンツであっても含まれていません のでご注意ください。

※電子版では、紙の雑誌と内容が一部異なる場合や、掲載されないページがある場合があります。

 

電子書籍は初めての方へ。マガストアで一度購入すると、スマホでもタブレットでもPCでも閲覧できます。

電子書籍は初めての方へ

総合ランキング
2024年11月05日

アプリダウンロード
はこちら

App Store でマガストアをダウンロード Android app on Google Play