クリーンアーキテクチャーのユーザー入力をチェックする場所について（CleanArchitecture）

Question

クリーンアーキテクチャーのユーザー入力をチェックする場所について質問です。
例えばユーザーが自分の名前を入力するとそれをDBに保存するアプリがあったとします。
そして 仕様書にユーザーは最大14文字の名前を保存できるという記載があります。

この場合、以下の図を参考にすると

引用先
http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

名前が14文字以下かどうかチェックする処理はEntitiesが担当すると考えています。
なぜなら14文字以下かどうかは仕様書に記載があり、これをビジネスルールだと考えているからです。

ではSQLインジェクション対策として、ユーザーが入力した名前にDBを操作するような危険な文字が入っていた場合、
変換するような処理を実装するとします。この「DBを操作するような危険な文字を変換する処理」は仕様書に記載がなく、
ビジネスルールとは言えないのではないかと思っています。そのためこの処理はEntities/Use Casesの外側の層で記載すべきと考えているのですが、この考えは合ってますでしょうか

お手数ですが、ご回答お待ちしております。

Answer 1

ではSQLインジェクション対策として、ユーザーが入力した名前にDBを操作するような危険な文字が入っていた場合、変換するような処理を実装するとします。この「DBを操作するような危険な文字を変換する処理」は仕様書に記載がなく、ビジネスルールとは言えないのではないかと思っています。

その通りです。

そのためこの処理はEntities/Use Casesの外側の層で記載すべきと考えているのですが、この考えは合ってますでしょうか

「記載」の意味が分かりませんが、SQLインジェクション対策の内容を仕様書や設計書等のドキュメントに一々書く必要はないでしょう。これは「SQLインジェクション対策は当たり前」のことだからです。SQL呼び出しの前にデータベース・サーバーに接続する旨を一々書かないのと同じ程度に書く必要のないことです。
では、どこに書くかというと、実装のルールブックのどこか、あるいは方式設計書等でSQL呼び出し（O/Rマッパーなど含む）の方法を記載して、その中で自動的にSQLインジェクション対策されているようにします。
このようにSQLインジェクションなど実装上の脆弱性の対策のドキュメント、システム内（場合によっては部門内）で包括的に記載しておけばそれでよく、処理の箇所毎に一々ドキュメントに記載するものではありません。

Comments

[Sagamaru]

失礼しました。質問の仕方が悪かったです・・・。来年新規プロジェクトが始まるのですが、今の現場のメンバーは誰もアーキテクチャーの知識がなく（あまり興味がない）、自分の方からリーダーにクリーンアーキテクチャーを導入しませんか？と提案しようと考えてました。そのためクリーンアーキテクチャーを勉強しているのですが、もし導入した場合、この処理はUseCaseが担当するのか、Entitiesが担当するのか、はたまたPresentersが担当するのか、といった質問がメンバーから来そうだなと思いました。

その質問を想像した場合、例えばユーザーが入力する機能があり、もし仕様書に記載がない入力文字のチェックや何か変換をする必要があった場合、それはクリーンアーキテクチャーのどこが担当するのだろう？と疑問に思ったため質問しました。記載と言い回しは良くなかったですね・・・。

ドキュメントの考え方など丁寧な回答ありがとうございました。

Answer 2

ではSQLインジェクション対策として、ユーザーが入力した名前にDBを操作するような危険な文字が入っていた場合、変換するような処理を実装するとします。

わたしが実装するとしたならば、「ユーザーが入力した名前にDBを操作するような危険な文字が入っていた場合、変換するような処理」を実装しません。チェックもしません。SQLインジェクションは、SQLを発行する際にプレースホルダを使うことで回避できるので、DB(Repository)まわりの実装で回避します。
SQLインジェクション対策が必要となるのは、SQLを発行するからです。通常のファイルに保存するのであれば不要です。SQLを発行するからSQLインジェクション対策を施す必要がある。だからSQLを発行する場所で対処します。

Comments

[Sagamaru]

回答ありがとうございます！とても納得できる説明でした。ベストアンサーにさせて頂きます。