コードの収まりどころ

収まりどころとは

処理がコーディングされる場所のことです。例えば、DBにアクセスする処理はRepositoryに記述したり、HTTPに関する処理はContollerに記述したりする、といった記述する"場所"を指しています。

図で理解する

ある一連の処理をHTTP関連の処理(H)、DBアクセス(D)、ビジネスロジック(B)に分けて、それぞれの収まりどころに記述していく例です。

一連の処理が分解され、各収まりどころに配置されていきます。

収まりどころを事前に用意し共有する

プロダクト開発の前段階で、どのようなアプリケーションアーキテクチャを採用するかやDDDを採用するかなどを決定する際に、収まりどころの種類を網羅させておきます。

ヘキサゴナルアーキテクチャであれば、HTTPやCLIやMQといったInput、ビジネスロジック、DBやAPIやMQといったOutputの3つにまず分けることが可能です。さらにDDDを採用するのであれば、コマンドモデルやクエリモデル、または、エンティティや値オブジェクトといった収まりどころを用意することになります。

この際、どういった処理は、どの収まりどころに配置されるかをチーム内で共有しておくことが重要になります。

早すぎる最適化

どんなに単純な処理をコーディングするにしても、事前に配置した収まりどころに分解する必要があります。DDDを採用しているのであれば、ビジネスロジックをサービスクラスに全て書く(トランザクションスクリプト)というようなことは推奨されず、エンティティやドメインサービスや値オブジェクトに配置する必要があります。

なお、プロダクトによっては、ほとんどビジネスロジックがなく、DBから取得した情報をそのまま、画面に表示するような機能がほとんどである場合、DDDの採用やヘキサゴナルアーキテクチャの採用はやりすぎの場合があります。Repositoryのメソッドを呼ぶだけのService層を書いた経験ある人は多いことと思います。図で説明すると下記のようなSerivce層にビジネスロジックがないようなものです。

そのため、Service層を取り除く欲求が生まれてきますが、現時点での仕様だけを前提に決定すべきものではありません。

もし、ControllerからRepositoryを直接呼ぶようなアーキテクチャを採用した場合、今後のビジネスロジックの追加には対応できません。(仕様をきっちり固めて、それ通り開発し、その後納品して保守はしない、というタイプの受託開発であれば、問題ないかもしれませんが。) ビジネスロジックをControllerかRepositoryに記述することになるので、"収まりが悪い"状態になってしまいます。

ビジネスロジックが追加された段階で、Service層を追加したり、DDDを採用すれば良いという話もあるかもしれませんが、基本的に「既存のコードはController-Repositoryの2層で書かれていたから、それに従った」というようなエンジニアは必ず出てくるでしょう。

良いアプリケーションアーキテクチャのイメージ

長期間にわたって保守性していくプロダクトの場合は、基本的には開発工数が多少高いが、改修の回数が増えても開発工数は微増していくだけ、となるようなアーキテクチャが良いです。

アーキテクチャの成長

とはいえ、良いアーキテクチャという理想を追い求め、成功するかわからないプロダクトに高いコストをかけていくのも、ビジネスサイドからの観点としては微妙です。

そのため、徐々に収まりどころを増やしていけるようにすることで、徐々に柔軟なアーキテクチャに成長させていくことこそ理想と言えます。

最初はController-Repositoryの2層でスタートし、徐々にService層を追加したり、値オブジェクトやエンティティを追加したりしていっても良いでしょう。

先の「既存のコードはController-Repositoryの2層で書かれていたから、それに従った」というようなエンジニアが出てこないように、アーキテクチャは成長しておくもの、ビジネスロジックが追加された場合はサボらずにService層を追加する、という認識を事前に共有しておくことが重要となります。 言い方を変えると、既存のアーキテクチャに従っておけば、それで十分ということはなく、各開発者が自発的にアーキテクチャを考え続ける必要があるということになります。(逆を言うと、既存のレールに乗っかっていくタイプの開発者が多い場合は、アーキテクチャは成長していくものという考え方はやめたほうが良いと言えます。)