4
ドメインとデータ永続性レイヤーのアーキテクチャ検証をクリーンアップしますか？
私はクリーンについて研究しており、その結果、ソフトウェアの設計と作成の方法について、かなり劇的に再考しています。 しかし、私がまだ取り組んでいることは、「一部のアイテムへの更新の保存時、最初の読み込みなど、表示/編集する権限のあるアイテムのすべてのリスト、このアイテムがリストにあることを確認するなどのビジネスルールです。そして、アイテムカテゴリは現在使用できないようにロックされていません（および他のルールなど） "。それは（複雑だが非定型ではない）ビジネスルールであり、ビジネスロジックをプッシュするのではなく、アプリケーションドメインで処理する必要があるためdb / persistenceレイヤー。 ただし、これらの条件を効率的にチェックするには、すべてのデータをアプリケーションドメインにロードするのではなく、巧妙に作成されたdbクエリで処理するのが最善のようです... 時期尚早な最適化なしで、推奨されるアプローチまたはこの質問を扱っているボブおじさんの記事は何ですか？または、「問題になるまでドメインで検証する」と言いますか？ 最も基本的な使用例以外の良い例やサンプルを見つけるのに苦労しています。 更新： みなさん、こんにちは。返信ありがとうございます。私はもっと明確で、長い間（主にWebアプリ）のソフトウェアを書いていて、まとめて記述したすべてのトピックを確実に経験して同意しているはずです（バックエンドで検証し、クライアントデータを信頼せず、一般的に言って）必要な場合にのみ生の効率を追跡しますが、利用可能な場合はdbツールの強みなどを認識し、「まとめて投げる」という開発者の学習ライフサイクルを経て「N層アプリケーションで巨大な脂肪コントローラーを構築する」コードのトレンド、そして今は基本的にクリーンで単一の責任のスタイルなどを非常に気に入って調査しています。最近のいくつかのプロジェクトの結果として、プロジェクトが進化し、クライアントの要件がさらに明らかになるにつれて、非常に不格好で広く分散したビジネスルールに発展しました。 特に、クライアント向けのREST APIと内部使用機能のためのREST APIを構築するコンテキストでクリーンスタイルアーキテクチャを検討しています。この場合、ビジネスルールの多くは、ネットで目にするすべての例よりもはるかに複雑になる可能性があります。（Clean / Hexアーキテクチャの開発者自身によっても）。 だから私は、CleanとREST APIがどのように共存するかについて本当に質問しました（そして明確に述べられなかった）と思います、ここで最近見られるほとんどのMVCには受信リクエストバリデーターがあります（たとえば。 「検証」ルールはそれほど「50文字未満の文字列ですか」ではなく、「このユーザーは、このユーザーケース/インタラクターを呼び出して、関連するオブジェクトが現在チームXによってロックされている場合、このデータのコレクションに対してこの操作を実行できますか？」月末までなど」...ビジネスドメインオブジェクトやドメインルールが多数適用される、非常に複雑な検証。 これらのルールを特定の種類のValidatorオブジェクトタイプにスピンアウトして、各ユースケースインタラクター（FluentValidatorプロジェクトからインスピレーションを得たものの、より多くのビジネスロジックとデータアクセスを伴う）に付随させる必要があります。それらの検証をゲートウェイ（間違っていると思います）などに配置します。 参考までに、このようないくつかの記事を書きますが、Mattiaは検証についてあまり説明していません。 しかし、私の質問への短い答えは、私が受け入れた答えに非常に似ていると思います：「それは決して簡単なことではなく、それは依存します」。