Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
33 lines (26 sloc) 2.8 KB
title tags
ContextualValidation
domain driven design
application architecture

http://martinfowler.com/bliki/ContextualValidation.html

ずっと、Validationについてまとまった記事を書きたいと思っていた。 Validationについては多くの混乱があるため、うまくいってる手法についてしっかりと述べるのはよいことだろう。 人生について書くことは多いが、その時間は限られている。

最近読んだ本に影響を受けて考えたある仮説について述べてみたい。 オブジェクトにValidation機能を実装するのはよく行われることである。 その手法は様々で、オブジェクト内に実装することもあれば、オブジェクトの外に実装することもある。あるいは、Validationの失敗を表すために、戻り値をbooleanにすることもあれば、例外をthrowすることもある。 しかし、私が気になるのは、コンテクストとは独立した形で(例えばisValidメソッドを使って)オブジェクトのValidationを行ってしまうことだ。

私はValidationをコンテクストと絡めて考えたほうが有用だと思っている。 コンテクストとは、通常、実施したい「アクション」になる。 例えば、この「注文」オブジェクトは完了しているか、この「顧客」オブジェクトはホテルにチェックインできるか、などだ。 つまり、isValidメソッドではなくisValidForCheckInのようなメソッドを用意するほうがよい。

以上のことから言えることは、オブジェクトをデータベースに保存することもアクションであるということだ。 このように考えると、ある重要な疑問がでてくる。 よく「コンテクストフリーなValidation」と言うとき、それはデータベースに保存するという観点から述べられる。 しかし、「このチェックを通らなかったものは保存しないほうがいいの?」 という疑問がでてくる。

著書『About Face』の中でAlan Cooperは、ユーザーに対して不完全な情報を入力(または保存)させないようにしてはいけない、と主張していた。 数日前、Jimmy Nilssonが現在執筆している原稿を読んでいてこのことを思い出した。 彼は、たとえエラーがあったとしても、オブジェクトは常に保存されなければならないと述べていた。 これはさすがに極端な話で、私も同意しかねるのだが、必要以上に保存を規制しているのは確かだろう。 Validationのコンテクストを考えると、そのことをいくぶん軽減できるのではないだろうか。

You can’t perform that action at this time.