「どこに書いてもとりあえず動く」から迷う

データの形が決まったら、次は処理です。困るのは、同じ処理をどこに書いても、とりあえず動いてしまうことです。画面の処理の中に業務のルールを書いても、テストは通ります。だから迷います。

3つの役割に分ける

まずは、処理を次の3つの役割に分けて考えます。

Rails の MVC（モデル・ビュー・コントローラ）も、この分け方の一つです。名前より、「この処理は、どの役割の仕事か」を毎回問うことが大事です。

ルールは1か所に

「締め切り後の求人には応募できない」というルールを、応募フォームの画面処理に書いたとします。あとで「スマホアプリからも応募できるようにしたい」となったら、同じルールをもう1回書くことになります。片方を直し忘れると、入口によってルールが違う状態になります。

naminori にも、応募を作る経路が2つあり、片方だけが社内への通知を送っていた時期がありました。同じ業務の処理が2か所にあると、こうしたずれが起きます。

本来の仕事と、ついでの仕事を分ける

もう1つ、naminori で実際に起きた不具合を紹介します。

応募の処理の中で、応募の保存と、社内への通知を同じひとまとまりの処理として書いていました。通知の処理に誤り（存在しない項目を読もうとしていた）があり、そこでエラーが起きると、処理全体が失敗扱いになりました。

その結果、応募はちゃんと保存されているのに、応募した人の画面には「失敗しました」と表示されることがありました。

直したあとは、保存が成功した時点で応募は成功とし、通知の失敗は記録だけ残すようにしています。ついでの仕事の失敗で、本来の仕事を失敗にしない。 そのためには、そもそも2つを別の仕事として分けておく必要があります。

• 画面・業務ルール・データの保存の3つの役割
• 業務ルールを1か所に置く理由
• 応募の経路が2つあった実例
• 本来の仕事と、ついでの仕事を分ける