2019-02-18

エラーの伝え方を調べてて今さらNotifcation Patternを知る

安易に例外を使ったり安易に例外をつぶしたりするコードになんか違和感があって調べてたんだけど、我らが Martin Fowler 先生の記事にたどりついた。で、

Replacing Throwing Exceptions with Notification in Validations

からの

Notification

からの

Separated Presentation

ですよ。

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 的な世界の話なのかなーくらいに思えてきた。あとはどんだけ言葉をそぎ落とすか、かなぁ。言葉が多いと言葉が目的化しちゃうのはフレームワークでもデザインパターンでもなんでも一緒な気がする。入り口に言葉を並べすぎるのはよくない。奥が深い程度の状態に留めておくのがよい。

  1. 別ルート作ってもよいかもしれない 

About

例によって個人のなんちゃらです