コンポーネントにおける上位・下位の混同をしない

上位・下位といった場合3つくらい考え方がある

1. 依存関係（コンパイル依存）

「どのコードが、どのコードを import してよいか」、ソースコード上で 一方向にしか許されない矢印

code:GraphQL

Resolver(presentation) → Usecase/Query → Domain → Repository（interface / impl）

Resolver から Usecase/Query をつかうのはありだが Repository を直接使うのは違反している、Repository が Query にあるメソッドに依存しているのは違反している、など

2. 抽象度・方針レベル

変更されにくいもの(=エンティティなど)を最上位として、実装の詳細を柔らかくする

ここにレイヤーリングをもちだすと混乱するのでしない、価値の序列だけを表す上位下位

https://gyazo.com/820f5c82808f678ab61fd89641f875a9

ソフトウェアのさまざまな領域を表している。一般的には、円の中央に近づくほどソフトウェアのレベルが上がっていく。円の外側は仕組み。内側は方針である。

ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければいけない。

円の内側は外側について何も知らない。特に、外側で宣言された名前は、内側にあるコードで触れてはいけない。

同様に、外側で宣言されたデータフォーマットは、内側から使ってはいけない。外側のフレームワークで生成されたフォーマットは特にそうだ。円の外側にあるものから内側にあるものに影響を及ぼしたくはない。

3. 実行の入口・データフロー

HTTPリクエストから受け取るパラメータがどうDBにクエリを投げて最終的に整形して出力するかといった方向をあらわす