2020-08-15 16:05:16

最近テスト可能な設計を実践した所感

初見のときのMVC

業務で実装するWEBアプリケーションは主にMVCのフレームワークを使用したアプリケーションでした。MVCフレームワークを使うとMVCに押し込めようとして何もかもが太ったコードになりがちでした。加えてデータベース操作に依存したメソッドをModelに押し込めてControllerから呼び出すという手法がよく行われていました。とりわけ、Controllerが太くなりがちでした。

Controllerを細身にする

MVCに押し込めるのをやめるためにアプリケーションサービスとして新たにディレクトリを追加してロジックをそこに入れる等してコードを細身にする試みを行いました。

この試みによってControllerがいくらか細身になりました。

Modelを細身にする

データベース操作をしているファイルではCRUD操作の全てをテーブルに対応した1ファイルに収めていました。収める必要なくない？というわけでCRUDに対応した4ファイルを作って操作しました。さらにModelでデータベース操作する必要なくない？ということで新たにデータベース操作をするためのディレクトリを追加してSQLをそこに閉じ込めました。もとのModelはドメイン固有の型として使用します。

この試みによってModelが細身になりました。

アプリケーションサービスではDIを利用する

以前まではControllerからModelをStaticで呼び出していましたが、これをするとユニットテストがデータベースに依存してしまいます。データベースに依存すると狙ったデータでユニットテストが出来ない上にテストが時間的に終わらなくなってしまいます。

アプリケーションサービスではデータベース操作を含むロジックを実装することになります。Controllerでデータベース操作のインスタンスをstaticではなくnewで生成して、アプリケーションサービスに渡すことによってユニットテスト可能にします。

アプリケーションサービスの粒度

そもそもControllerの粒度も曖昧ですが、アプリケーションサービスのファイルの粒度も曖昧だったりまします。インスタンス変数が全てのメソッド内で使われているかどうかを基準にしてファイルを分けるか検討します。もちろん検討した結果、ファイル分けをしない場合もあります。結構曖昧です。

チーム内の共有について

積極的に共有したわけではありませんでした。もちろん相談された場合は自分が実装するつもりになって一緒に考えることもありました。テスト実行可能な状態になっていれば良しとして考えていたためコードの細かい部分のレビューなどは行っていませんでした。自分が書いたコードを参考にしてくれたためか、ほとんどすべてのコードがテスト実行可能な状態であったため今の所問題なさそうです。

でもどこかのタイミングで各ディレクトリの意図・変数の名前の意図・ファイルの粒度などを共有しておきたいです。