単一責任の原則について誤解していた話
自分の誤解
単一責任の原則と聞いて「モジュールは1つのことだけをやるべきだ」と単純に思っていました。
しかし、今回調べてみるとそうではないことに気づきました。
改めて単一責任の原則とは
Clean Architecture では次のように述べられています。
モジュールを変更する理由はたったひとつだけであるべきである
モジュールはたった1つのアクターに対して責務を負うべきである
— 81ページ
アクターとは
アクターとは、そのモジュールに変更を求める人や仕組みのことです。
たとえば、モジュールの機能を使うユーザーや、そのモジュールを利用する他のプログラムがアクターにあたります。
つまりどういうこと？
一見すると複数の処理を持っているように見えるモジュールでも、アクターが1つならば単一責任とみなせるということです。
ただし、やっていることが似ていても、アクターが異なる場合はモジュールを分ける必要があります。
具体例で考えてみる
モジュールを分けなくていい場合
例えば、ユーザー情報をアップデートする機能について考えてみましょう。
このモジュールは以下のような処理を含んでいます。
- データベースから対象のユーザーを取得する
- 対象のユーザー情報を更新する
一見、「ユーザーの取得」と「ユーザーの更新」は別の処理に見えますが、どちらも「ユーザー情報をアップデートしたい」という単一のアクターの要求を満たすための一連の処理です。
変更理由が「アップデート機能の仕様変更」という1つに集約されるため、単一責任の原則に反していません。
モジュールを分けるべき場合
一方で、共通の処理でもアクターが異なる場合にはモジュールを分けるべきです。
例えば、同じ「ユーザー情報を扱う」機能でも、以下のような状況を考えます。
- ユーザー自身がプロフィールを編集する機能
- 管理者がユーザーの情報を編集する機能
これらは「ユーザー情報を更新する」という共通点がありますが、アクター（管理者と一般ユーザー）が異なります。
それぞれのアクターが異なる変更理由を持つ可能性が高いため、1つのモジュールにまとめると管理や変更が複雑になり、単一責任の原則に反する設計となります。
結論
- 単一責任の原則は「モジュールが1つの変更理由だけを持つこと」が大事。
- 処理が複数あっても、対象が1つのアクターであれば分ける必要はない。
- アクターが違えば、モジュールを分けるべき。
- 「何のため」「誰のため」にモジュールがあるのかを考えるのが重要。
最後まで読んでいただきありがとうございました！
Discussion