Webシステムの場合、画面表示を扱うフロントエンドとデータを扱うバックエンドを分けているケースが大半だと思います。
サーバーやネットワークまで分けているかはシステムの規模やセキュリティ要件によって異なるでしょうが、少なくともクラスは分けているのではないかと思います。
しかし、フロントエンドとバックエンドの境目が曖昧なため、本来フロントエンドにあるべき処理がバックエンドに入っているケースが散見されます。
例えば、「DBの検索結果が0件だったらエラーを返す」ような処理です。
結果が0件だった場合にどうするか決めるのは本来、フロント側の仕事です。
バックエンドは、要求されたデータがあれば箱に詰めて返す、無ければ空っぽの箱を返すという、例えれば倉庫番のような存在であるべきです。
返された箱が空っぽだった場合、ユーザーに対して見せるのが「無かったから他の条件で検索してみて」なのか、「無かったけど、ほんとにこの○○あるの？」なのか、「ごめん、絶対あるはずなんだけど…何か問題があって取得できなかった」なのかを決めるのはフロント側の役割です。
どういう目的でフロントエンドがデータを要求しているのか、バックエンドは知らないはずですし、知る必要はありません。
要求されたデータが無いということがあり得ることなのか、それともあってはいけないことなのか、知らないはずのバックエンドが勝手にエラーにしてしまうのはおかしいです。
もちろん、「そもそもDBにアクセスできなくて結果が0件だった」ような場合は完全にバックエンド側のエラーなので、単純にデータが無かった場合としっかり区別する必要があります。
もしそれを区別していない場合、倉庫番が鍵が無くて倉庫に入れなかったのに何事も無かったかのようにしれっと空っぽの箱を返してきてるようなものなので、重大な欠陥と言えます。
次の例は、「カラムAとカラムBは必ずセットで画面に表示するから、文字列結合してからフロントエンドに返す」のように、画面表示の仕様に合わせてデータを整形してから返す処理です。
これも、本来はフロントエンドでやるべき処理です。
バックエンドはあくまでも要求された条件に合致するデータを返すだけであり、そのデータがどこでどう使われるのか意識する必要はありません。
最低限、ひと固まりのデータとして不自然じゃない形への整形は必要ですが、それ以上の整形は不要です。
確かに、バックエンドでデータ取得と同時に整形した方が効率がいいという考え方も一理ありますし、その方がパフォーマンスがいいかもしれません。
しかし、フロントとバックそれぞれに与えられた役割は何だっけ？と考えると、画面表示用の整形をバックエンドでやるのは不自然だと思います。
画面の仕様が変わって改修が必要になった際など、修正が必要な整形処理がどこにあるか分からずにフロントとバックの両方を探さなければならなくなるため、保守性も大幅に低下します。
バックエンドは言われた通りのデータを倉庫から取ってくるという役割に徹し、そのデータをユーザーに見せるための料理はフロントエンドに任せるべきです。
データ取得の例が続きましたが、データ登録も同様です。
バックエンドは、外が見えない＆見る必要が無い倉庫番です。
従って、渡されたものをそのまま倉庫にしまいに行く（＝登録する）だけです。
もちろん最低限、登録が可能かどうかの型チェックや必須チェック、他のデータとの整合性チェックなどは必要ですが、画面の入力値チェックに相当するような細かいチェックをバックエンドで実施するのはおかしいです。
また、画面に入力された値を登録用に整形するのもフロントエンドの役割です。
ここは、「あれ？DBに登録するための整形なんだからバックエンドの役割では？」と思われるかもしれませんが、違います。
なぜならば、バックエンドは画面の仕様を知らないからです。
画面の仕様を知らないので、どの項目がどう入力されるか分からず、整形もできないはずです。
従って、フロントエンド側で倉庫にしまえる形に箱詰めしてからバックエンドに渡してやる、というのが正しい形になります。
箱詰めの仕様が、フロント-バック間のインターフェースというわけです。
今回例として挙げたフロントエンド・バックエンドに限らず、その部分に与えられた役割は何か、この処理は役割に合っているか、ということを常に意識しながらプログラムを書くことが保守性の向上につながると思います。