アーキテクチャ上どのレイヤでバリデーションするのか | wapa5pow blog
DDDやレイヤードアーキテクチャでアプリケーションを書いているとどのレイヤで値のバリデーションをしていくか迷う時があります。 レイヤーが増えたときに多くの場所でバリデーションを書きすぎると重複したコードが増え可読性も生産性も下がります。 レイヤごとに行うバリデーション それではどのレイヤでどのようなバリデーションをすればいいのでしょうか。以下のようにするといいのではと思っています。 フロントエンド ユーザの入力はシステムで想定されていない値がくるかもしれないので必要ならバリデーションを行います。 ただフロントエンドでバリデーションは、直接リクエストを変更しサーバにリクエストを投げることにより改変可能なので信用してはいけません。 あくまで最終的なバリデーションはサーバで行うとして多くのリクエストをサーバに投げられるのを防ぐためやサーバにいちいちリクエストしてユーザの利便性を損なうならばバリデ
新しくプロダクト開発に入ったときにやっていること | wapa5pow blog
年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
