あとからこの過去記事を読み返して「ムム」と思うところがあったので改めて。
CategoryId
ではなくCategory
を引数として渡すことでデータ構造が隠蔽されているという旨の説明をしているが、これはfetchArtclesByCategory
を呼び出す側の責務が「Category
の データとしてIDが取れる」という知識を持ってしまうのを防げるという意味で書いたのではないかと思う。けれどもその実装だと、結局
fetchArticlesByCategory
関数側が、引数として受け取るCategory
からIDを取り出すという処理をせなばならず、ID呼び出しでないという設計指針がfetchArticlesByCategory
に対してCategory
への依存を与えてしまっている。この依存が別に構わないという可能性もあり、たとえば
Category
がドメインモデルなのであれば、そのドメインモデルに対して単方向の依存を持つクリーンアーキテクチャ的観点でいうところの外部のレイヤとしてfetchArticlesByCategory
が存在していると考えることもできるので、さほど問題を感じなくなる。ところで
fetchArticlesByCategory
関数を呼び出すのは、アプリケーションの責務のうち誰になるのだろうか... またまたクリーンアーキテクチャを考えてしまうが、おそらくユースケース層ではないかと思う。DDD的観点:
CategoryId
を渡す場合においての別の懸念点としては、もしもCategoryId
がCategory
という集約ルートにおける値オブジェクトだとしたら、それをCategoryId
単体で受け取ってしまえるインターフェースもった関数fetchArticlesByCategoryId
があることで、利用者によって不変条件を保たずにつくられたおかしなCategoryId
が渡ってくる可能性があるのではないかということ。正直ここは実装の問題のような気もするけど...

Clean Architecture 達人に学ぶソフトウェアの構造と設計
- 作者: Robert C.Martin,角征典,高木正弘
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/07/27
- メディア: 単行本
- この商品を含むブログを見る