0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【CleanArchitecture】コンポーネントの凝集性についてのまとめ

Last updated at Posted at 2024-12-30

久しぶりにCleanArchitectureを復習したので、今の理解を残しておこうと思います。

■ コンポーネントとは

まず、コンポーネントとは 「システムの一部として独立してデプロイ・再利用できる最小限のまとまり」 のことです。
そして、コンポーネントには一貫したテーマや目的があり、コンポーネントの構成要素はコンポーネントの目的と関連性の高いものでなければなりません。

■コンポーネントの凝集性

凝集性とは

コンポーネントが担う責務や機能がどの程度のまとまりを持っているかを示す概念で、具体的には 「コンポーネントの責務が一つに絞り込まれているか」 「構成要素がコンポーネントの責務と強い関連性を持っているか」 を図る指標となります。
「高い」または「低い」で表します。

  • 凝集性が高い
    • 単一の責務に特化している
    • コンポーネントの責務を達成するための関連性の強い要素のみで構成されている
    • メンテナンス性・再利用性が高い
  • 凝集性が低い
    • 複数の異なる責務を持っている
    • コンポーネントの責務と関連性の薄い構成要素が雑多に詰め込まれている
    • 一つの変更に対する修正範囲が大きい

コンポーネントの凝集性を評価するには3つの原則が材料となります。

  1. 再利用・リリース等価の原則(REP) (再利用性のためのグループ化)
    再利用可能な単位でひとまとめにすること
  2. 閉鎖性共通の原則(CCP) (保守性のためのグループ化)
    同じ理由、同じタイミングで変更されるものはひとまとめにすること
  3. 全再利用の原則(CRP) (不要なリリース作業を減らすための分割)
    不要なものに依存しないこと

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

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

つまり、再利用可能な単位でひとまとめにすること

再利用の単位でクラスやモジュールをコンポーネントにまとめ、再利用の単位でリリースできなければいけないということです。
コンポーネントを再利用の単位で作成し、再利用の単位でリリースできるようにすることで、コンポーネントの再利用がしやすくなります。

この原則を無視すると...
再利用の際に複数のコンポーネントを参照しなければならなくなり、バージョンの互換性の考慮が発生するなど、再利用が難しくなります

◎閉鎖性共通の原則(CCP)

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

※ 単一責任の原則(SRP)をコンポーネント向けに言い換えたもの

つまり、同じ理由、同じタイミングで変更されるものはひとまとめにすること

コンポーネントが、変更理由や変更タイミングが同じ要素で構成されていれば、一つの変更に対して一つのコンポーネントの変更とデプロイ行うだけで良くなります。
つまり、変更に対して閉じている(=閉鎖性)ということです。

  • 単一責任の原則(SRP)
    クラスを変更する理由が複数あるべきではない
  • 閉鎖性共通の原則 (CCP)
    コンポーネントを変更する理由が複数あるべきではない

この原則を無視すると...
同じ理由、同じタイミングで変更されるべきリソースが複数のコンポーネントに散らばっていると、一つの変更で複数のコンポーネントの修正が必要になります。(修正範囲の拡大)
異なる理由、異なるタイミングで変更されるべきリソースが同一コンポーネントにまとまっていると、一つの変更が関係ない機能に影響を及ぼす可能性があります。(影響範囲の拡大)
どちらもメンテナンス性が低下します。

◎全再利用の原則(CRP)

コンポーネントのユーザーに対して、実際には使わないものへの依存を強要してはいけない

※ インターフェイス分離の原則(ISP)をコンポーネント向けに言い換えたもの

つまり、不要なものに依存しないこと

コンポーネントに依存する場合、コンポーネントに含まれるすべてのクラスに依存すべきで、依存するクラスもあれば、しないクラスもあるという状況は避けるべきということ。
コンポーネントが本当に必要な依存先にのみ依存することで、不要な依存先の変更に起因するリソースを避けることができます。

  • インターフェイス分離の原則(ISP)
    使っていないメソッドを持つクラスに依存しないこと
  • 全再利用の原則(CRP)
    使っていないクラスを持つコンポーネントに依存しないこと

この原則を無視すると...
コンポーネントが不要な依存先に依存することで、不要な依存先の変更の影響ででリリースを強制されるようになります。

◎コンポーネントの凝集性のテンション図

これら3つの原則はすべて遵守すべきといったものではありません。

再利用・リリース等価の原則(REP)全再利用の原則(CRP) はコンポーネントを大きくする方向に働き、 全再利用の原則(CRP) はコンポーネントを小さくする方向に働くといった点で3つの原則にはトレードオフな部分があり、どの原則を重視するかはプロダクトの状況によってバランスを取りながら変えていく必要があります。
これら3つの原則のバランスを上手く取るのがアーキテクトの腕の見せ所です。

テンション図

テンション図は3つの原則がそれぞれどのように影響を及ぼし合うかを示したもので、辺にある記述は反対側の頂点にある原則を無視したときにかかる コスト を表しています。

  • 再利用・リリース等価の原則 (REP)全再利用の原則 (CRP) にだけ力を入れていると
    • 些細な修正で多くのコンポーネントの修正が必要になったり、一つの修正が関係のない他の機能に影響を及ぼします
  • 再利用・リリース等価の原則 (REP) ** と ** 閉鎖性共通の原則 (CCP) にだけ力を入れていると
    • コンポーネントの依存先が増え、不要な依存先の変更に起因した不要なリリースが増加します
  • 全再利用の原則 (CRP)閉鎖性共通の原則 (CCP) にだけ力を入れていると
    • 再利用の単位が複数のコンポーネントにまたがり再利用しづらくなります

component_02.drawio.png

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?