達人出版会 | 夏休みに読みたい!インプレス&近代科学社フェア
手を動かしてわかるクリーンアーキテクチャ  ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発

手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発

Tom Hombergs

インプレス

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

PDF EPUB
SALE 3,300円 1,650円 (税込)
ギフト用に購入

書籍情報

著者: Tom Hombergs
共著者: , 須田智之(訳)

発行日: 2024-07-19
最終更新日: 2024-07-19

バージョン: 1.0.0
ページ数: 288ページ(PDF版換算)ページ
対応フォーマット: PDF, EPUB
出版社: インプレス

対象読者

ソフトウェア設計に興味を持っているソフトウェア開発者・クリーンアーキテクチャとは何か/実装方法を知りたいソフトウェア開発者

著者について
Tom Hombergs

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

目次

序文

はじめに

訳者まえがき

第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 結論

索引