2022-08-05

これが（アーキテクチャ的な意味での）アプリケーションサービスですか

趣味コードを書いていたときに思ったことを書いた

いつもと違うやり方をした

何かコードを書くとき、自分はいつも必要になるところから順番に書いていく。DFS みたいな、木構造で言うと葉の部分から書いていく感じ。テストも一緒に書いていき、モジュールが順番に完成していく。

ある日、なんとなくインタフェースやシグネチャを全部先に書いてみることにした。クラスも関数も全部モック。「あ、ここ〇〇の処理いるじゃん」って思ったら、普段ならその処理をする関数を書き始めるところ、今回はその処理をする予定の空の関数を用意して実装を進めていく。

「この処理をするクラス・関数の名前は何かな？」とか「この処理はどのファイルにあるのが自然かな？」ということを考えて、今は何もしないクラスと関数を生成していく。

詳細な実装は何もないので、データを永続化したり値を返すことは一切できない。できないのにコードが書ける。実行してコードの動きを確かめることはできないけど、自分の期待する処理が書ける（テストコードがないので間違ったコードを書いている可能性は当然ある）。

データをどうやって保存するかは書いてないけど、ここでデータを保存するという宣言はできる。そうやって実装を進めると、実際には何もしなくて、ただ指示を出している関数の存在が明らかになってくる。この関数は、具体的な実装が全くないのにちゃんと仕事をしていますみたいな雰囲気を出している。

ただ指示を出すだけの関数は、ありものを順番に呼び出しているだけである。いろいろなモジュールに依存しているが、ほとんど依存されていない。期待する処理を実行するために、仕事の順番を調整しているその姿、これがアプリケーションサービスですか。

関数（メソッド）には抽象度みたいな概念がある。抽象度が高いものだけを組み合わせて、これまた抽象度の高い処理が書ける。

具体的な処理がない関数は何をするのかわからなくて、パラメータ、戻り値、名前から推測するしかない。関数の名前とやってほしい処理が一致しないとすごく困る。また、型を付ける、特にプリミティブな型じゃなくて何らかのオブジェクトをやり取りするように書くと情報量が増える（使い所は難しい）。

依存関係は DAG みたいになっていそう。それらを抽象度ごとにまとめて綺麗なレイヤーができていれば、関数の粒度が揃っていそう。