Screaming Architecture
プロジェクトを見れば、それが何をするのか、何についてのものなのかがわかるようにする
アーキテクチャが「これは〇〇なものだぞ！」と叫んでいるようにする
directoryを眺めた時に、ツール依存の用語ではなく、Use Case依存の用語を前面に出すべき
frameworkは詳細であり、それに類する用語が最初に目に入るのはおかしい
例えば、Reactで言えば
components/ とか hooks/ のようなdirが上部に存在しているのは良くない「Reactを使っている」ということは詳細であり、アプリケーションにとっては些末なこと
決定を遅延させ、選択肢を残しておくにも関連する
「Reactを使う」などの詳細の決定を遅延させられる
言うなれば、Package by Usecaseにする
>アーキテクチャが振る舞いをサポートするために最も重要なことは、 アーキテクチャレベルでシステムの意図がわかるように、振る舞いを明らかにすることである。 優れたアーキテクチャを備えたショッピングカートのアプリケーションは、ショッピング カートのアプリケーションのように見える。システムのユースケースは、システムの構造のな かにハッキリと見えるようになるのだ。開発者は振る舞いを探すことがなくなる。振る舞いは ファーストクラスの要素として、システムのトップレベルにあるからだ。このような要素には、 クラス、関数、モジュールなどがあり、アーキテクチャでは目立った位置にいる。また、それ ぞれの機能を明確に示す名前が付けられている。
Architectureに限らずあらゆるパーツを叫ばせるべき
Robert C. Martinの文書を読むと具体例がdirectoryなので、それに限定してしまいそうになるが、抽象化の余地がある
dirctoryレベルで見れば、PBFに前提に置くと、1つのFeatureとはなにかの指針になる
詳細を知りすぎた上でfeatureを考えるのではなく、叫んだ時にわかりやすいものを選択する
file treeを見ただけで、存在目的が分かるように工夫する
sub packageでもそれを再帰的に適用する
「
表現 を使って 対象 を叫ばせる」の組み合わせは多分に考えられそうScreaming Architectureの本質が、「〇〇を見れば、そのアプリケーションが何なのかわかる」だとすると、
〇〇の
表現 と 対象 って、かなりの組み合わせが候補になりそう 表現 の例file tree
config file (適当)
コードに対する工夫を上下に汎用するに書いたレベルのあらゆるモノ
etc.
対象 の例feature
entity
etc.
例えば、PBFは、「file treeを使って、featureを叫ばせる」ということをしてる
「コンセプトで叫ばせる」ってなんか魅力的では
言うて、file treeって割と限界ありそう
階層構造だし、跨ぐものをどうするか問題が解決できない
コードに対する工夫を上下に汎用するの話にも繋がる
file treeで叫ばせきれなかったものを、別のレベルで叫ばせる
>
