公開されてます。今回は開発手法「くーす」に関する資料がメイン。開発手法に対するモヤモヤが晴れてスッキリします。これをベースに自前のテンプレート作ってみよう。
でも個人的にはバリデーションの設計は、データの整合性を保障するために、原則できるだけデータアクセス層のエンティティレベルで行いたい。なぜなら、同じエンティティに対する更新操作でも、フロント系機能から入力される場合、管理系機能から入力される場合、それも新規登録画面と、更新画面があって、さらにCSV一括登録があって…と、バウンダリが異なる場合もあるし、業務ロジックだって異なる場合もある。それにプレゼンテーション層でバリデーション設計してしまうと、checkboxやselectなどの項目の入力チェックが漏れてしまうなんて事故もありそう。バリデーションを低階層で行うのは、特に「フロント系機能と管理系機能で開発担当者が違う」と言った時に有効だと思うのだが。
コメント
2004/9/10 05:17 from ひが
2004/9/10 13:21 from みやまえ
ひがさん、降臨ありがとうございます！ なるほど。くーすとしてはバリデーションをどの層で実装するかは関知しないということですね。
よく見たらpptに書いてありましたね…。個人的にはやはり「更新画面」「追加画面」「管理系・・」とあった場合に、それぞれの画面に対してバリデーション仕様を書くと、不一致、漏れが起きそうな気がするので、エンティティ定義書のほうに書きたいかな。という感じです。しかしエンティティ定義書はユーザーにレビューしてもらう資料ではないと思うので、微妙なところもあります。
バリデーションには、要求仕様としてものもと、非要求仕様としてのものがあります。べつに分けて考えることはないと思うのですが、特に後者はセキュリティやデータの正当性などの点で重要なのに、無知や手抜きから無視される場合も少なくありません。なので、エンティティ仕様の一部としてのバリデーションについて、きちんと枠組みを作っておきたいなあ、と考えています。ビジネスロジック層を書く人はバリデーションを気にしなくてもいいように。
Webアプリフレームワークではバリデーションの仕組みを備えたものが多いですけど、基本的に画面単位を想定したものです（ビュー＆コントローラのフレームワークなのだから当然だけど）。これに従ってしまうとバリデート漏れが起きそうでちょっと怖いのです。
バリデーションの定義が画面の設計書にありますが、
プレゼンテーション層で実装するという意味では
ないです。
あくまでもユーザへのヒアリング用です。
どの層で実装するのかは、実装フェーズで考えます。