Clean Architecture 達人に学ぶソフトウェアの構造と設計

関連サイト

本書の関連ページが用意されています。

• Clean Architecture - アスキードワンゴ

内容紹介

本書は、"Robert C. Martin. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017. 978-0134494166"の全訳である。著者は、アジャイル開発とオブジェクト指向の世界で有名な「アンクル・ボブ」ことRobert C. Martin。彼の最新刊である本書は、これまでに発刊された『Clean Code』『Clean Coder』に続く「Clean」シリーズの3作目となっている。

本書で扱うテーマは「アーキテクチャ」。目次を見てすでにお気づきかもしれないが、みなさんが「アーキテクチャ」という言葉から想像するイメージとは、少し違った内容になっているだろう。著者の考えるアーキテクチャとは「設計」であり、一般的なイメージよりも具体的なものとなっている。その一方で、ビジネスドメインに関係のないことは「詳細」と割り切り、デリバリーの仕組みやフレームワークなどをすべて後回しにしようとする。おそらく異論のある方もいらっしゃるだろう。私もすっきりしていない。たとえば、ウェブアプリケーションを開発するときに、フレームワークを選定しないことがあるだろうか？

だが、著者はこれまでの経験を引き合いに出しながら、圧倒的な説得力で力強く迫ってくる。お前のアーキテクチャは、見ただけでわかるようになっているのか？　ドメインについて正しく叫んでいるのか？　そのように問いかけてくる。第21章から引用しよう。

最上位レベルのディレクトリ構造と最上位レベルのパッケージのソースファイルは、「ヘルスケアシステム」「会計システム」「在庫管理システム」と叫んでいるだろうか？　それとも「Rails」「Spring/Hibernate」「ASP」と叫んでいるだろうか？

フレームワークから着手しないことが本当に正しいことなのかは、私にはまだよくわからない。本書で紹介されている例は、いずれも現代的なアプリの話ではない。正直、大昔の話を何度もされても困るのだが（翻訳も大変だし）、それでも「時代を超越した不変のルール」が存在するとして、著者はいつまでも原理・原則に忠実であろうとする。この真摯な態度については、心から見習いたい。彼が「ソフトウェアクラフトマンシップ（職人気質）」と呼んでいるものだ。本書で提唱されている「Clean Architecture」については、すでに著者本人がブログや講演などで情報発信していることもあり、見よう見まねでアーキテクチャの「同心円」を実装している例が数多く見られる。だが、著者のように原理・原則に忠実であるためにも、まずは本書に目を通してもらいたい。そして、著者と対話しながら、自らのアーキテクチャをクリーンにしてもらえれば幸いだ。

（「訳者あとがき」より）

書誌情報

• 著者: Robert C. Martin(著), 角征典, 髙木正弘(訳)
• 発行日: 2018-07-27 (紙書籍版発行日: 2018-07-27)
• 最終更新日: 2018-07-27
• バージョン: 1.0.0
• ページ数: 352ページ(PDF版換算)
• 対応フォーマット: PDF, EPUB
• 出版社: アスキードワンゴ

対象読者

著者について

Robert C. Martin

Robert C. Martin（アンクル・ボブ）は1970 年からプログラマである。cleancoders.com の共同創業者であり、ソフトウェア開発者向けの学習用動画をオンラインで提供している。また、Uncle Bob Consulting LLC. を設立し、世界中の大企業を対象としたソフトウェアコンサルティング、トレーニング、スキル開発を行っている。シカゴに本拠地を置くコンサルティングファーム8th Light, Inc. では、Master Craftsman を務めていた。さまざまな業界誌に寄稿し、国際的なカンファレンスや展示会でも頻繁に講演している。「C++ Report」の編集長を3 年間務め、Agile Alliance の初代委員長でもあった。
著書に『The Clean Coder（邦訳：Clean Coder ― プロフェッショナルプログラマへの道）』『Clean Code（邦訳：Clean Code ― アジャイルソフトウェア達人の技）』『UML for JavaProgrammers（邦訳：Java プログラマのためのUML）』『Agile Software Development（邦訳：アジャイルソフトウェア開発の奥義）』『Extreme Programming in Practice（邦訳：XPエクストリーム・プログラミング実践記― 開発現場からのレポート）』『More C++ Gems』『Pattern Languages of Program Design 3』『Designing Object Oriented C++ ApplicationsUsing the Booch Method』がある。

角征典

ワイクル株式会社代表取締役、東京工業大学環境・社会理工学院特任講師。アジャイル開発やリーンスタートアップに関する書籍の翻訳を数多く担当し、それらの手法を企業に導入するコンサルティングに従事。主な訳書に『リーダブルコード』『Running Lean』『Team Geek』（オライリー・ジャパン）、『エクストリームプログラミング』『アジャイルレトロスペクティブズ』（オーム社）、『図解リーン・スタートアップ成長戦略』（日経BP社）、『Clean Coder』（アスキードワンゴ）、共著書に『エンジニアのためのデザイン思考入門』（翔泳社）がある。

髙木正弘

1972年大阪府生まれ。都内で会社員として働く傍ら、主にソフトウェア開発関連の技術文書の翻訳に携わる。日本酒とカメラと飛行機を好む。主な訳書・共訳書に『実践ドメイン駆動設計』（翔泳社）、『継続的デリバリー』（アスキードワンゴ）、『プログラミングPHP』（オライリー・ジャパン）がある。

目次

まえがき

序文

• 謝辞
• 著者について

第I部　イントロダクション

第1章　設計とアーキテクチャ

• 目的は？
• ケーススタディ
• まとめ

第2章　2つの価値のお話

• 振る舞い
• アーキテクチャ
• 大きな価値
• アイゼンハワーのマトリックス
• アーキテクチャの戦い

第II部　構成要素から始めよ：プログラミングパラダイム

第3章　パラダイムの概要

• 構造化プログラミング
• オブジェクト指向プログラミング
• 関数型プログラミング
• 考えるべきこと
• まとめ

第4章　構造化プログラミング

• 証明
• 有害宣言
• 機能分割
• 正式に証明できない
• 救済のための科学
• テスト
• まとめ

第5章　オブジェクト指向プログラミング

• カプセル化とは？
• 継承とは？
• ポリモーフィズムとは？
• まとめ

第6章　関数型プログラミング

• 整数の二乗
• 不変性とアーキテクチャ
• 可変性の分離
• イベントソーシング
• まとめ

第III部　設計の原則

第7章　SRP：単一責任の原則

• 症例1：想定外の重複
• 症例2：マージ
• 解決策
• まとめ

第8章　OCP：オープン・クローズドの原則

• 思考実験
• 方向の制御
• 情報隠蔽
• まとめ

第9章　LSP：リスコフの置換原則

• 継承の使い方の指針
• 正方形・長方形問題
• リスコフの置換原則（LSP）とアーキテクチャ
• リスコフの置換原則（LSP）違反の例
• まとめ

第10章　ISP：インターフェイス分離の原則

• インターフェイス分離の原則（ISP）と言語との関係
• インターフェイス分離の原則（ISP）とアーキテクチャとの関係
• まとめ

第11章　DIP：依存関係逆転の原則

• 安定した抽象
• Factory
• 具象コンポーネント
• まとめ

第IV部　コンポーネントの原則

第12章　コンポーネント

• コンポーネントの簡単な歴史
• リロケータビリティ（再配置可能性）
• リンカ
• まとめ

第13章　コンポーネントの凝集性

• 再利用・リリース等価の原則（REP）
• 閉鎖性共通の原則（CCP）
• 全再利用の原則（CRP）
• コンポーネントの凝集性のテンション図
• まとめ

第14章　コンポーネントの結合

• 非循環依存関係の原則（ADP）
• トップダウンの設計
• 安定依存の原則（SDP）
• 安定度・抽象度等価の原則（SAP）
• まとめ

第V部　アーキテクチャ

第15章　アーキテクチャとは？

• 開発
• デプロイ
• 運用
• 保守
• 選択肢を残しておく
• デバイス非依存
• ダイレクトメール
• 物理アドレス
• まとめ

第16章　独立性

• ユースケース
• 運用
• 開発
• デプロイ
• 選択肢を残しておく
• レイヤーの切り離し
• ユースケースの切り離し
• 切り離し方式
• 独立した開発が可能
• 独立デプロイ可能性
• 重複
• 切り離し方式（再び）
• まとめ

第17章　バウンダリー：境界線を引く

• 結合の悲しい物語
• FitNesse
• あなたの境界線は何か？　いつ境界線を引くのか？
• 入力と出力はどうする？
• プラグインアーキテクチャ
• プラグインの戦い
• まとめ

第18章　境界の解剖学

• 境界を越える
• 恐怖のモノリス
• デプロイコンポーネント
• スレッド
• ローカルプロセス
• サービス
• まとめ

第19章　方針とレベル

• レベル
• まとめ

第20章　ビジネスルール

• エンティティ
• ユースケース
• リクエストとレスポンスのモデル
• まとめ

第21章　叫ぶアーキテクチャ

• アーキテクチャのテーマ
• アーキテクチャの目的
• だが、ウェブはどうか？
• フレームワークはツールであり、生き方ではない
• テスト可能なアーキテクチャ
• まとめ

第22章　クリーンアーキテクチャ

• 依存性のルール
• 典型的なシナリオ
• まとめ

第23章　プレゼンターとHumble Object

• Humble Objectパターン
• プレゼンターとビュー
• テストとアーキテクチャ
• データベースゲートウェイ
• データマッパー
• サービスリスナー
• まとめ

第24章　部分的な境界

• 最後のステップを省略する
• 片方だけの境界
• Facade
• まとめ

第25章　レイヤーと境界

• Hunt the Wumpus
• クリーンアーキテクチャ？
• 流れを横切る
• 流れを分割する
• まとめ

第26章　メインコンポーネント

• 究極的な詳細
• まとめ

第27章　サービス：あらゆる存在

• サービスアーキテクチャ？
• サービスのメリット？
• 子猫の問題
• 救世主のオブジェクト
• コンポーネントベースのサービス
• 横断的関心事
• まとめ

第28章　テスト境界

• システムコンポーネントとしてのテスト
• テスト容易性のための設計
• テストAPI
• まとめ

第29章　クリーン組込みアーキテクチャ

• 適性テスト
• ターゲットハードウェアのボトルネック
• まとめ

第VI部　詳細

第30章　データベースは詳細

• リレーショナルデータベース
• なぜデータベースシステムが普及しているのか？
• もしもディスクがなかったら？
• 詳細
• だけど、パフォーマンスはどうなの？
• 小話
• まとめ

第31章　ウェブは詳細

• 止まらない振り子
• 結論
• まとめ

第32章　フレームワークは詳細

• フレームワークの作者たち
• 一方的な結婚
• リスク
• 解決策
• 今あなたたちを夫婦として宣言する
• まとめ

第33章　事例：動画販売サイト

• プロダクト
• ユースケース分析
• コンポーネントアーキテクチャ
• 依存性管理
• まとめ

第34章　書き残したこと

• レイヤーによるパッケージング
• 機能によるパッケージング
• ポートとアダプター
• コンポーネントによるパッケージング
• 悪魔は実装の詳細に宿る
• 組織化かカプセル化か
• そのほかの分割方法
• まとめ：言い残したこと

第VII部　付録

付録A　アーキテクチャ考古学

• 組合の会計システム
• レーザーカット
• アルミダイキャストの監視
• 4-Tel
• サービスエリアコンピュータ
• C言語
• BOSS
• pCCU
• DLU/DRU
• VRS
• 電子受付
• 転送システムの作成
• 明確なコミュニケーション
• ROSE
• アーキテクト登録試験
• まとめ

あとがき

訳者あとがき

訳者について

索引