クリーンアーキテクチャ本とは

皆さんご存知こちらの名著のこと。割と古い本のはずだけど最近あちこちでオススメされてる(自分の観測範囲だけ？)。

本の構成は以下のようになっている。

第Ⅰ部イントロダクション
- 1章設計とアーキテクチャ
- 2章２つの価値のお話
第Ⅱ部構成要素から始めよ: プログラミングパラダイム
- 3章パラダイムの概要
- 4章構造化プログラミング
- 5章オブジェクト指向プログラミング
- 6章関数型プログラミング
第Ⅲ部設計の原則
- 7章単一責任の原則
- 8章オープン・クローズドの原則
- 9章リスコフの置換原則
- 10章インターフェース分離の原則
- 11章依存関係逆転の原則
第Ⅳ部コンポーネントの原則
- 12章コンポーネント
- 13章コンポーネントの凝集性
- 14章コンポーネントの結合
第Ⅴ部アーキテクチャ
- 15章アーキテクチャとは？
- 16章独立性
- 17章バウンダリー: 境界線を引く
- 18章境界の解剖学
- 19章方針とレベル
- 20章ビジネスルール
- 21章叫ぶアーキテクチャ
- 22章クリーンアーキテクチャ
- 23章プレゼンターとHumble Object
- 24章部分的な境界
- 25章レイヤーと境界
- 26章メインコンポーネント
- 27章サービス: あらゆる存在
- 28章テスト境界
- 29章クリーン組み込みアーキテクチャ
第Ⅵ部詳細
- 30章データベースは詳細
- 31章ウェブは詳細
- 32章フレームワークは詳細
- 33章事例: 動画販売サイト
- 34章書き残したこと
- 35章アーキテクチャ考古学

この本で特に重要なのは第Ⅲ部〜第Ⅴ部にかけての部分なので、この要点まとめシリーズでは7章〜29章の要点と自分の所感を1章ずつ記事にまとめていく。

第Ⅲ部 7章単一責任の原則

SRPとは

単一責任の原則(SRP, Single Responsibility Principle)が言わんとするのはどのモジュール・関数もたった一つのことを行うべきということではなく、あくまで 「モジュールを変更する理由はたった一つだけであるべきである」 ということ。

ここでいう「変更の理由」とは、そのソフトウェアのユーザーやステークホルダーを指す。ユーザーは一人とは限らず、複数人がシステムを変更したいと望む場合もあるため、これらシステムの変更を望む人達をひとまとめにしたグループのことを アクター と呼ぶ。するとSRPはより正確には以下のように言い換えられる。

「モジュールはたった一つのアクターに対して責務を負うべきである。」

給与計算システムの例で考える

これを説明するために本文中で紹介されている給与計算システムの例が分かりやすかったので紹介する。この例では給与計算システムに従業員クラスが存在し、そこに以下2つのメソッドが実装されている状況で何が起こるかを考えている。

給料を計算するメソッド: calculatePay
- 計算ロジックは経理部門が規定する
- 計算結果の報告先はCFO
労働時間を計算するメソッド: reportHours
- 計算ロジックは人事部門が規定する
- 計算結果の報告先はCOO

このような設計では、給与計算と労働時間の計算の両方で同じように所定労働時間を算出している場合などに、開発者はコードの重複を排除するためこの計算をregularHoursメソッドに切り出そうと考えるはずである。
その後ある時CFOチームで所定労働時間の計算方法を変えたくなったため、regularHoursメソッドに手を加えたとする。するとその修正について何も知らされていないCOOチームは知らぬ間に数字がずれていることに気付かず、後になって大問題が発覚するというわけだ。

このような事故が起こった原因は、アクターが違う処理(この例でいうとregularHourメソッドが担当している処理)をメソッドに切り出して共通化しまったことにあるというわけだ。なので具体的な実装の観点でSRPを言い換えるなら、 「アクターが異なる処理はメソッドやモジュールに切り出して共通化してはいけない」 という風に言えそうである。

自分はこの給与計算システムに関する説明を最初に読んだ時、
「テストコードがどのアクター目線でも網羅的に書かれていてCIで全てのテストケースをチェックする体制ができていればこういう事故はある程度機械的に防げるのでは？」
という想いが一瞬頭をよぎったが、冷静に考えると問題はそこではなく、一つのアクター目線で修正を加える際に常に他のアクターの事情も考慮しなればならないという時点でまず開発効率が落ちるということだと思う。

Facadeパターンによるコード分割

SRPを説明する例としてもう一つ、複数のアクターが別々の理由で一つのソースファイルを変更したい状況(CTOチームとCFOチームがEmployeeクラスを共通で利用しており、そのクラスを変更したいような場合)の解決策についても触れられている。ここでも、アクターの異なるコードは分割すべき の原則に従うことになる。

やることとしては、

Employeeクラスが持つメソッドを全て削除し、このクラスには最低限のデータ構造のみもたせる
Employeeクラスが持っていた個々のメソッドの処理内容を対応するサービスクラスに実装し直す
Employeeクラスが元々備えていたメソッドを呼び分けるためのEmployeeFacadeクラスを用意。このクラスの各メソッドで、実際に実行したい処理を担うサービスクラスをインスタンス化して処理を移譲する

これでEmployeeクラスが多方から修正されることを防ぎ、かつクラスを小さく保つことができるようになる。

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (Robert C. Martin)