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

この記事について

• Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ際の覚え書きです

覚え書き

ひとつのコンポーネントを形成するクラスやモジュールは、まとめてリリース可能でなければいけない

同じバージョン番号を共有し、同じプロセスを経て、同じリリースドキュメントを持っていると言う事実は、作者にとってもユーザーにとっても合理的なはずだ。

• 再利用・リリース等価の原則（REP）とは再利用されるコンポーネントの単位とリリースされるコンポーネントの単位を一致させること
  • 一致していると
    • ユーザーが変更内容を確認したうえで適用するか判断できるようになる
  • 一致していないと
    • 変更内容がわからない
    • 変更の適用の仕方がわからい

同じタイミングで変更されることが多いクラスは一つにまとめておけということだ。

まとめておけば、ソフトウェアのリリースやデプロイの際の作業量を最小限に抑えられる。

• 閉塞性共通の原則（CCP）とは同じタイミング、同じ理由で変更するものはひとつのコンポーネントにまとめる
  • まとめると
    • 変更コンポーネントを最小限に絞ることができる

どのクラスをひとまとめにすべきではないかを伝える原則だ

密結合していないクラスを同じコンポーネントにまとめるべきではない

• 全再利用の原則（CRP）とはひとつのコンポーネントに含まれるクラスやモジュールは密結合にする
  • コンポーネント内が密結合になると
    • コンポーネント間の依存が発生しにくくなる
      • コンポーネント間の依存が発生しないと
        • コンポーネント単位でリリースすることができるようになる
      • コンポーネント間の依存が発生すると
        • ひとつのコンポーネントをリリースするために依存するコンポーネントもビルドする必要がある
• インターフェイス分離の原則（ISP）は使っていないメソッドを持つクラスに依存しないようにする、全再利用の原則（CRP）は使っていないクラスを持つコンポーネントに依存しない（対象が違うだけ）

まとめ

• 原則を守ることが大事ではなく、プロジェクトやコンポーネントの性質に合わせた取捨選択が大事
  • 再利用・リリース等価の原則（REP）を徹底すると
  • 閉塞性共通の原則（CCP）を徹底すると
    • 関連するクラスをコンポーネントにまとめるため、利用者によっては利用しないクラスがコンポーネントに含まれてくる
      • 全再利用の原則（CRP）に反してしまう
  • 全再利用の原則（CRP）を徹底すると
    • 関連したクラスが各コンポーネントに散らばるため、一つの変更が大量のコンポーネントに影響してしまう
      • 閉塞性共通の原則（CCP）に反してしまう
• 各原則の分割方法（プロジェクトが進むに連れてCCPからREPに移行する傾向がある）
  • 閉塞性共通の原則（CCP）→ 保守しやすい分割
  • 再利用・リリース等価の原則（REP）→ 再利用しやすい分割
  • 全再利用の原則（CRP）→ リリース作業を減らす分割