この記事の続きです

「なんでも出来る画面」からの卒業

「会員情報を変更するぞー」という画面があって、そこで名前も住所も電話番号も支払い方法も何もかも変更できるようになっている、というのはよくある設計ですが、それだと画面とバックグラウンドを繋ぐ処理のところが大わらわになってしまって、修正がしづらい画面になってしまいます。

そこで、名前なら名前、住所なら住所、と項目ひとつひとつについて変更するための画面を用意しておき、名前を更新する処理、住所を更新する処理……と、画面表示のためのクラスもひとつひとつ用意しておきます。

そうすれば、クラスを小さく保ち、変更箇所を狭い範囲に留める事ができます。

その後もし「えー、でもー、まとめて変更できる画面の方がいいしー」となっても、用意しておいた小さいクラスを組み合わせて何でも画面を実現すれば、裏側は小さいまま、「何でも画面」も作ることが出来ます。

「小さい画面」の方が便利な時代になった

名前を変える時には名前を変える画面、住所を変えるなら住所画面……と、一々あっちこっち移動するのは不便なようにも思いますが、実際のところ、名前も住所も電話番号も支払い方法も一気に変えることってそんなに頻繁にはなくて（全部まとめて変わるとしたら、結婚/離婚と同時に引っ越す場合くらいでしょうか）、変えたい部分だけ変えられればいいわけで。

さらに、スマホの普及や回線の増強により、「チョコチョコ通信が切れがちかつ画面が小さい環境からの利用」が増え、と同時に「とはいえチョコチョコ通信してもユーザーに嫌がられない環境」が整ったため、「通信回数減らして通信容量削減するために、一気に入力させて一気に登録処理しましょう」より、「途中で通信切れても大丈夫なようにチョコチョコ通信して、1ステップずつ登録処理しよう」の方が便利な時代になってきている、と言えそうです。

ですので、「大きい画面」を一つ用意するよりも、「小さい画面」を沢山用意して組み合わせて使うようにした方が、ユーザーもらくちんで、開発も容易、ということになります。

業務システムで、絶対パソコンからしかアクセスされないことが分かっており、業務上どうしても「大きい画面」の方が効率が良い、という場面があるなら、それはそれとしてアリでしょうが、あくまでも裏側は小さく作ることを意識した方が良さそうです。

画面の関心事とオブジェクトの関心事を一致させる

ドメイン駆動設計においては、「利用者の関心事」を単位として考えます。

で、利用者は「画面」を通じてシステムを使います。

利用者がある画面を見たとき、そこに、とある関心事についての情報が全てまとまって表示されていない／余計な情報までわんさか表示されている、ということになれば、それは不便です。

ですから、ある関心事についての情報は、過不足無く一つの画面に収まっていて欲しい訳です。

そして、ある画面に表示させるための一連の情報群は、一つのオブジェクトとしてまとまっていて欲しい訳です。

となればもう、あるオブジェクトの関心事と、ある画面の関心事は一致してくるはずです。うまく一致しないなら、画面かオブジェクト、どちらかの設計を見直すべきサインとなります。

表示にまつわる業務ロジックもドメインモデルに閉じ込めたい

例えば「納期が迫っている取引だけ強調表示したい」という場合。

「表示に関することはUI層の担当」ということで、コントローラーに

if(order.getDeadline > today + 3){

    class = "bold";

}else{

    class = "nomal";

}

とか書きたくなりますが、それをやってしまうと「納期が迫っている取引は強調表示する」ことが必要な全ての画面のコントローラーに、同じif文が増殖してしまいます。

考えようによっては「納期まで三日を切ったら、ヤバい案件と認識する」というのも一つの業務ロジックなので、これもドメインモデルに閉じ込めてしまった方が、変更が容易です。

class Order{
// もろもろ略
public String deadlineStatus(){}
    if( isDeadlineLooms() ){
        return "awful";
    }
    return "nomal";
}

と、ドメイン側に判断ロジックを閉じ込めて、クラス名をリターンするようにしておいて、HTML側で

<span class = "${order.deadlineStatus()}">

とクラス名を呼び出すようにすれば、UI層からif文を追い出せます。やったね。

同様に、「検索結果が0件だったとき」と「0件じゃなかったとき」でメッセージを出し分けたいような場合も、オブジェクトの側に判断ロジックとメッセージを閉じ込めておくのが良さそうです。

HTMLタグはオブジェクトに持たせない

一方で、HTMLタグなどは完全に「表示に関する事」であり、例えば同じテキストを、将来的にCSVに出力するとか、別のAPIに渡すとか、そういう処理が追加されることも考えられるので、htmlタグそのものをオブジェクトに持たせてしまうと、「CSVにしたときにhtmlタグが入り込んで来る～～～」「APIに渡して登録したら余計な改行が増えてる～～～」みたいなことが起きる可能性があります。

なので、htmlタグそのものはオブジェクトには持たせず、UI層（controllerやHTMLテンプレート自身）に持たせるようにします。

この続きはこちら