エラーの伝え方を調べてて今さらNotifcation Patternを知る
安易に例外を使ったり安易に例外をつぶしたりするコードになんか違和感があって調べてたんだけど、我らが Martin Fowler 先生の記事にたどりついた。で、
Replacing Throwing Exceptions with Notification in Validations
からの
からの
ですよ。
API クライアントが UI を持つ場合、何らかのアクションに応じてサーバでエラーが起きたらそれをフィードバックする必要があって、そのためには
- サーバ側の Error を詰め込んだオブジェクトをバケツリレー(?)1して
- これは Model から独立しててよい
- API(presentation)まで運んで
- クライアントに返して
- クライアントは Model で受け取って
- いい具合に Error を表示するだけに集中する人に渡すといい
って考えてたんだけど、ほぼまんま書いてあったわ…。15年前にガイシュツやったわ…。
※ Data Transfer Object も出てくるね
Notification て名前は今だと UI の Pattern のようにも見えるけど、ここでは observeに対する notify くらいの意味かな。
にしても JS ヘビーにはしない方がよいとずっと思ってたけど、間違ってなかったな。そっちに舵を切るにはフレームワークのケアしない領域の羅針盤が必要だけど Web 側の知見は不十分で、いわゆるクライアント-サーバモデルの GUI アプリケーションの知見がまさにハマってきそう。
フロントエンドの世界では .NET のノウハウが Angular 1 辺りから入ってきてたけど、最近 Scala で DDD って話も結局 JavaEE 的な世界の話なのかなーくらいに思えてきた。あとはどんだけ言葉をそぎ落とすか、かなぁ。言葉が多いと言葉が目的化しちゃうのはフレームワークでもデザインパターンでもなんでも一緒な気がする。入り口に言葉を並べすぎるのはよくない。奥が深い程度の状態に留めておくのがよい。
別ルート作ってもよいかもしれない ↩