Clean Architecture コンポーネントの原則

 コンポーネントとは、デプロイの単位。システムの一部としてデプロイできる。

再利用・リリース等価の原則(REP)

 再利用の単位とリリースの単位は等価になる。

閉鎖性共通の原則(CCP)

 同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。

 これは、単一責任の原則(SRP)をコンポーネント向けに言い換えたもの。単一責任の原則(SRP)は「クラスを変更する理由が複数あるべきではない」という原則だが、閉鎖性共通の原則(CCP)は「コンポーネントを変更する理由が複数あるべきではない」と説いている。

 多くのアプリケーションにおいて、再利用性よりも保守性の方が重要。アプリケーションのコードを変更しなければいけないときには、ひとつのコンポーネントに変更箇所がまとまっているほうが、あちこちのコンポーネントに散らばっているよりもありがたい。変更箇所がひとつのコンポーネントに閉じていれば、変更後にデプロイする必要があるのはコンポーネントだけになる。そのコンポーネントに依存していないコンポーネントは再デプロイする必要がない。

 閉鎖性共通の原則(CCP)が伝えようとしているのは、同じタイミングで変更されることが多いクラスはひとつにまとめておけということ。2つのクラスが物理的あるいは概念的に密結合していて、変更のタイミングがいつも一緒になるのであれば、それは同じコンポーネントに属するもの。まとめておけば、ソフトウェアのリリースやデプロイの際の作業量を最小限に抑えられる。

 この原則は、オープン・クローズドの原則(OCP)とも密接に関連している。実際、閉鎖性共通の原則(CCP)で扱う「閉鎖性」は、オープン・クローズドの原則(COP)の「クローズド」と同じ意味。オープン・クローズドの原則(OCP)では、クラスは修正に対して閉じていて、拡張に対しては開いていなければいけないと定めている。完全に閉じるのは不可能なので、戦略的に進めていく必要がある。クラスの設計時には、想定できるものや過去に経験したことがあるものなど、よくある種類の変更に対して閉じるようにしておく。

 閉鎖性共通の原則(CCP)は、この教えからさらに噛み砕いて「変更の種類が似ているクラスをひとつのコンポーネントにまとめる」とした。こうすることで、要件変更があった場合の変更箇所を最小限のコンポーネントに絞れる。