書籍
Clean Architecture
達人に学ぶソフトウェアの構造と設計
Robert C. Martin
概要
ビジネスロジックをフレームワークやDBから分離し、独立してテスト可能なシステム構造を構築するための 依存性逆転の原則に基づく普遍的設計原則を解説。
編者の視点
関数・クラス単位の品質を終え、システム全体の境界と依存の向きを設計したい人向け。 原則の射程が広く規模を問わず効く設計判断の軸を与える。具体実装より思想を学ぶ本。
対象読者
- アーキテクチャ設計に携わるエンジニア
- Clean Code既読の中級開発者
タグ
奥付
- 出版社
- KADOKAWA
- ISBN
- 978-4048930659
- 出版日
- 2018年7月
- 参考定価
- ￥3,520税込Amazonの実売価格と異なる場合があります
この本を手に入れる
※ 上記は Amazon アソシエイトによる広告リンクです。関連書籍
前提となる書籍
- 推奨前提
Java言語で学ぶデザインパターン入門
結城浩
理由: クラス単位のパターンを使いこなせるようになったら、システム全体の依存の向きと境界をどう設計するかという上位の視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える依存性のルールを与える。
- 推奨前提
Spring徹底入門
Spring FrameworkによるJavaアプリケーション開発
株式会社NTTデータ
理由: Spring でひと通りアプリを組めるようになると、フレームワークに引きずられた設計（DB やフレームワーク中心）の限界に気づく。クリーンアーキテクチャはビジネスルールをフレームワークから独立させる依存性のルールを与え、長期的に変更に強い構造を選べるようにする。
- 推奨前提
Clean Code
アジャイルソフトウェア達人の技
Robert C. Martin
理由: 関数やクラス単位の品質が身についたら、次はシステム全体の依存の向きと境界を設計する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える原則を与える。
- 参考
オブジェクト指向における再利用のためのデザインパターン
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
理由: クラス／オブジェクト単位のパターン語彙を得たら、それらを束ねてシステム全体の依存方向と境界を律する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える。
次に読む書籍
- 推奨前提
モノリスからマイクロサービスへ
モノリスを進化させる実践移行ガイド
Sam Newman
理由: システム内部の境界を設計できるようになったら、その境界をプロセス＝サービスへ分割すべきかという次の判断へ進む。Monolith to Microservices は「まずモノリスから」という現実的な指針のもと、分割の動機・進め方・落とし穴を体系立てる。
- 推奨前提
マイクロサービスパターン
Microservices Patterns
Chris Richardson
理由: 境界と依存の原則を一つのプロセス内で設計できたら、その原則を分散システムへスケールさせる。Microservices Patterns は各サービスの内部設計（アーキテクチャ）を保ちつつ、サービス間の通信・整合性・障害をどう設計するかの語彙を与える。
- 推奨前提
単体テストの考え方/使い方
Vladimir Khorikov
理由: 依存の向きを制御するアーキテクチャを学ぶと、そのテスタビリティの恩恵を最大化するテスト設計の原則が欲しくなる。単体テストの考え方/使い方は「良いテストとは何か」を定義し、アーキテクチャが生む疎結合をテストの価値に変換する。
- 推奨前提
ソフトウェアアーキテクチャの基礎（第2版）
エンジニアリングに基づく体系的アプローチ
Mark Richards, Neal Ford
理由: クリーンアーキテクチャで「あるべき形」の直観を得たら、アーキテクチャ特性やトレードオフを体系的な語彙で扱えるようにする。本書は属人的な設計判断を、議論可能な工学へと引き上げる。
- 推奨前提
ドメイン駆動設計をはじめよう
ソフトウェアの実装と事業戦略を結びつける実践技法
Vlad Khononov
理由: 依存の向きを制御できるようになると、次の関心は「境界をどこに引くか」へ移る。ドメイン駆動設計はビジネスの言葉から境界づけられたコンテキストを導き、アーキテクチャの分割に意味を与える。
- 推奨前提
A Philosophy of Software Design, 2nd Edition
John Ousterhout
理由: 依存と境界の原則を得たら、その根底にある「複雑性をどう抑えるか」という普遍的な問いへ降りる。Ousterhout は深いモジュール・情報隠蔽という観点で複雑性管理を体系化する。
- 推奨前提
チームトポロジー
価値あるソフトウェアをすばやく届ける適応型組織設計
Matthew Skelton, Manuel Pais
理由: 技術的な境界を設計できるようになったら、その境界がチーム構造と相互に影響し合う事実（コンウェイの法則）へ視野を広げる。アーキテクチャはコードだけでなく組織の問題でもある。
- 推奨前提
マイクロサービスアーキテクチャ
第2版
Sam Newman
理由: 依存方向と境界の原則は、サービス境界の設計にそのまま効く。境界づけられた責務を、独立にデプロイ可能な単位へ写像する具体的な設計判断へつなげる。
- 推奨前提
エンタープライズ アプリケーションアーキテクチャパターン
Patterns of Enterprise Application Architecture
Martin Fowler
理由: 層と依存方向の原則を得たら、それを実装へ落とす定番パターン（Repository・Service Layer・Domain Model）の原典へ進む。原則とパターンが対応づくと設計の語彙が一段深まる。
- 参考
失敗から学ぶRDBの正しい歩き方
曽根壮大
理由: アーキテクチャ上はデータベースを「詳細」として外側に置くが、その詳細であるリレーショナル設計を疎かにすると現場で破綻する。アンチパターンを通じてスキーマ設計の勘所を押さえ、抽象の理想と実装の現実を両立させる。