たとえばSPAにおいて 「あるカテゴリに紐づく記事一覧を取得する」 という実装があるとする
このような処理を実装するにあたっては、各レイヤによって知ってよいことと、知っててはいけないものが変わってくる。
例えばバックエンドが、RDBMSのようなIDによってデータを区別するようなミドルウェアを使っているのであれば、むろんAPIの呼び出しなどを行うデータアクセス・レイヤへアプリケーションが保持しているエンティティのIDがなんらかの方法で渡ることになるが、以下のように明示的にデータ構造がIDという属性を持っているということを期待している（＝知っている）ようなコードを書くのは良くないと思っている。
const articles = fetchArticlesByCategoryId(category.id)
- この実装を自分が改善するとしたら、以下のようにする
const articles = fetchArticlesByCategory(category)
この改善によって、
fetchArticlesByCategoryはもうcategoryのデータ構造を知る必要がなくなった。これは、categoryのデータ構造の変更が発生したとしてもfetchArticlesByCategoryを使うレイヤは影響を受けない（＝変更に強い）ことを意味する。fetchArticlesByCategoryはその名前から分かるようにリポジトリ・レイヤの責務なので、リポジトリがcategoryなどの依存するドメイン・モデルのデータ構造を処理の中で知識として持っていることは問題ない。バックエンドの仕様が変わってIDの代わりにカテゴリ名でフィルタするようになりました！ みたいになっても、リポジトリ・レイヤだけ弄ればよいので、ドメイン・レイヤは変更から守られる。もっと言うと、ドメイン・レイヤの中に
idみたいなインフラ・レイヤを感じさせるような言葉が出てくるのがすでに危険信号のように見える。それともidがインフラ・レイヤを感じさせる、というのは自分がRDBMSのことを考え過ぎなのだろうか...ちなみにこの記事は書いててデメテルの法則だな〜と思った。
