MVCのMとVとCの分け方について考えてみる

最近、MVCでM(モデル)とV(ビュー)とC(コントローラ)の境界が
自分の中で曖昧になっているなと思うので、
どのように分離されるべきかをこの記事に随時追記していくことにする。

2021/01/05 追記
おそらく、MVC自体は、
アプリケーションのイベント通達や処理フローの一連の流れを決定するもので、
それぞれの境界がどこかというのは、また別の話なのかもしれないです。
DDDやクリーンアーキテクチャをやっているうちに、私の中で考えがまとまったものだと思います。
なので、このタイトル自体すこし、気持ち悪いニュアンスなのかもしれないです。
ただ、私がそうだったように、
MVCでアプリケーションを作るってなったときに、
これはどっちに書くべきなのだろうという疑問が幾度となく出てきて、
悩んでしまう人に、すこしでもヒントになれば良いかなと思いタイトルはそのままにしておきます。
悩んで自分なりの答えをだせるのなら、その方が良いともおもったり。
（そもそも全然まだ記載できてないですが。）

また、MVCだけでなく、MVVMやMVPでも分ける単位的には対してはあまりどのアーキテクチャにしても、
影響はしないのではないかと思います。
それぞれ、CをVM,Pに置き換えれば、同じことが言えるのではないかと。

筆者環境 Java,SpringBoot,Thymeleef

MとV

スマートUIにならないように気をつける。
→http://d.hatena.ne.jp/minekoa/20100116/1263657955

1.ビューに==は使わない。

例えば、Stateというenumがあって、

<div th:if="${model.state == State.SUCCESS}">成功しました！<div/> 

とするのであれば、

<div th:if="${model.isSuccess()}">成功しました！<div/> 

とした方が良いのではと思う。

でないと、
model.stateとState.SUCCESSが一致した時、成功であるという、
ビジネスロジックがビューに染み出ているのではないかとおもいます。
そんなことはビューは知らなくて良いと思います。

2.判断、加工はモデルに、表現の方法はビューに(WIP)

MとC

1.バリデーションの実行はビジネスロジック？コントローラー？（WIP）

バリデーションの持ち場所って難しいなとは思うのですが、
基本的にはバリデーションを行うのはプレゼンテーション層(View or Controller)で良いかなと思っています。
バリデーションで使用する、判断ロジックがドメイン固有のものなのであれば、
その処理だけをドメイン側(model)にもってくるというのが、
僕の中で今の所しっくり来てるんですよね。
ちなみにエラーを表示するのはViewで、エラーハンドリング、エラー画面へ遷移はControllerですね。
TODO：サンプル記載