Clean Architectureにおいてバリデーションはどこでやるべきか
クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同
要件と機能の関連を保つテンプレート
品質の鍵は上流工程にあり SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON（ダンジョン）」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用！業務システムの開発ドキュメント標準化」（http://www.thinkit.co.jp/free/project/4/1/1.html）にて紹介したところ、大変好評でした。 その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTful Web アプリの設計レビューの話
