問題タブ [domain-object]

サービス層に検証コードを配置するように言っている本や記事の例をたくさん見てきました。ドメイン オブジェクトを「ダム」(別名、純粋な POCO) に保ち、ドメイン オブジェクトがサービス層で行う可能性のあるすべての検証を処理します。

サービス層は、見かけ上（または少なくともそうである可能性があります）、非常に多くの責任を負っています。ユーザー認証、ロール認証、IoC の依存関係オブジェクトのスクリプト作成 (ロガー、エラー ハンドラーなど)、ドメイン オブジェクトのスクリプト作成、リポジトリのスクリプト作成、およびリポジトリとの間でのドメイン オブジェクトの受け渡し...

サービス層でこれらすべてのルールを作成することは、ドメイン オブジェクトに重大な脅威をもたらしませんか? たとえば、一部のプログラマーがドメイン オブジェクトに対して直接消費するコードを記述し、サービス層を完全にバイパスすることを決定した場合はどうなるでしょうか? それは悪いことですが、信じられる状況です。

すべてのドメイン オブジェクトの検証を含め、サービス層に多くの責任を負わせようとしている場合、誰かがそれらを直接スクリプト化しようとしたときに、ドメイン オブジェクトを「保護」する方法はありますか? たとえば、何らかの方法でドメイン オブジェクトが特定のクライアント (この場合はサービス層?) によって使用されていない可能性があります。

優れた設計とは、ドメイン オブジェクトが、誰が呼び出しているのか、どのように呼び出されているのかについて何も知らなくてもよいと私に思わせるものです。

ドメイン オブジェクトを「ロックダウン」する方法がない場合、ドメイン オブジェクトの検証をサービス レイヤーに配置することを提案する記事や書籍が非常に多いのはなぜですか? 防御的なプログラミングの立場を取ることで、ドメイン オブジェクトを防弾となるように構築し、UI と BAL/DAL の間で要求を転送および受信するための単純なコード レイヤーとしてサービス レイヤーに依存する必要があると想像できます。

サービス層を迂回した人々によるドメイン オブジェクトの「悪用」について、実際のプロジェクトで経験した人はいますか?

ソフトウェア アーキテクチャにおけるドメイン オブジェクトとドメイン サービスとは何ですか? 私はそれらに精通していないか、ビジネスロジックレイヤーとどのように違うのですか?

ドメイン オブジェクトから Zend へのクイックスタート チュートリアルの例と、DAO/VO パターンを考慮した他の例を見ると、両者は非常に似ているように見えます。

「値オブジェクト」と言うのは「ドメイン オブジェクト」と同じだと推測できますか?

そうでない場合は、それらの違いを明確にしていただけますか?

あるものの機能は何ですか？

どちらもゲッターとセッターによって構成されており、それ以上のものではないため、私はこれを求めています。どうやら、彼らは同じ機能を果たしているようです...

アップデート：

そのため、Zend Framework クイック チュートリアルのドキュメントでは、これをドメイン オブジェクトと呼んでいました。

1)厳密に言えば、「Anemic Domain Object」に直面しているのでしょうか?

2）ドメインロジックが含まれているという理由だけで「ドメインオブジェクト」と呼ばれていますか？

3)この場合、findBookByAuthor() などのメソッドを含むマッパー。彼らはドメインロジックも扱っていますよね？それらもドメインオブジェクトと見なすことができますか?

どうもありがとう

私が間違っている場合は、私を修正してください。

以下を表すドメイン モデルと言えます。

a) MVC 構造の M 部分。M 部分にはドメイン駆動設計パターンが適用されています。

b)実体、それらの属性、および特定の方法での関係のスキーム。MVC の M 部分を表すこともできますが、この場合、使用されるパターンに関係なく。

c)「ドメイン モデルが相互接続されたオブジェクトのウェブを作成する」ドメイン モデル デザイン パターン。

d)ドメイン オブジェクトとして (たとえば、特定のドメインに関する MVC モデルのオブジェクトである可能性があります)。

d)はb)と同じだと言えますか?

どうもありがとう。

私の ORM は、データベースのテーブル構造を反映したオブジェクトを生成しています。このオブジェクトは拡張可能であるため、新しいプロパティとメソッドを追加できます。このオブジェクトには永続化ロジックが含まれていないため、永続化を無視していると思います。

このオブジェクトをドメイン オブジェクトとして使用する必要がありますか?それともメイン ドメイン モデル用に新しいオブジェクトを作成する必要がありますか?

新しいオブジェクトを作成するプロとして、データベーステーブルが変更されてもアプリケーションが壊れることはないと考えています。

新しいオブジェクトを作成するための短所として、追加のマッピングとアプリの複雑さを検討します。

ドメインロジックはドメインオブジェクトに配置する必要があることを私は知っています。しかし、ドメインロジックがデータベースからのデータを必要とする場合はどうなりますか？（たとえば、一意の値、計算された値などをチェックする）ドメインオブジェクトにリポジトリを挿入することは正しいことではないと思います。また、サービスレイヤーにビジネスルールを含めることはできません。では、この種のビジネスロジックをどのように解決するのでしょうか。

Grailsドメインオブジェクトでvalidate（）を呼び出して受け取った開発者指向の検証エラーリストをユーザー指向のエラーメッセージに変換する最良の方法は何ですか？

例：
値[x]のクラス[classtestproj.AuthUser]のプロパティ[email]は有効な電子メールアドレスではありません

むしろそれを読んでもらいたい：
与えられた電子メールは有効な電子メールアドレスではありません

すでにこれを行っている組み込みのものはありますか？

セットでドメインオブジェクトを使用するのは悪い習慣ですか、それともマップでキーとして使用するのは悪い習慣ですか？

過去に私はこのようなことをたくさんしました

findAllByAuthorLikeただし、Hibernate Proxyオブジェクトのリストを返す可能性com.me.Book_$$_javassist_128があるfindByTitleLikeが、適切なオブジェクトを返す場合に問題が発生することがよくありcom.me.Bookます。これにより、実際のオブジェクトとプロキシが等しくないと見なされるため、セット内で重複が発生します。

このようなドメインオブジェクトのセットを使用するときは、細心の注意を払う必要があると思います。そもそも、それは私がすべきではないことかもしれないと感じています。

もちろん、別の方法はIDのセット/マップを使用することですが、コードが冗長になり、誤解されやすくなります。

@Burt：少なくともオブジェクトインスタンスではなくclass /idでequals/compareが実行されるように、Grailsドメインクラスはすでにこれを実行していると思いました。休止状態のプロキシ用の特別なコンパレータを意味しますか？

私が取り組んでいるプロジェクトでは、Hibernate オブジェクト (*.hbm.xml ファイルにマップされているもの) は接尾辞 "Hib" で終わるという規則があります。たとえば、「UserHib」や「OrderHib」などがあります。

これが便利な理由は、dao レイヤーの外側にあるコードを見ると、これらのオブジェクトがドメイン オブジェクトであることが非常に直感的にわかるからです。また、潜在的な問題 (遅延初期化、プロキシ オブジェクトなど) のフラグも立てます。

ここで、通常の jdbc レイヤーを介してアクセスおよび作成されるいくつかのドメイン オブジェクトを追加する必要があります。同じ接尾辞を使用すると、混乱 (.hbm.xml ファイルに見つからない新しいオブジェクト) が増えるか、混乱が減りますか (ドメイン オブジェクトの統一された接尾辞)?

何かご意見は？

クラスから継承するいくつかのクラスがありますAdmin：Manager、、Translatorなど。

Adminは集合体であるため、独自のリポジトリが必要です。ただし、マネージャーまたはトランスレーターを見つけるためのいくつかのメソッドは、これらのクラスに固有である可能性があります。その他は、すべての管理者に共通である可能性があります。

ここでのベストプラクティスは何ですか？するべきか：

• 管理者を見つけるためのすべてのメソッドを1つのリポジトリに配置しますか？
• または、リポジトリの階層を使用してドメインモデルクラスの階層を模倣ManagerRepositoryしTranslatorRepository、AdminRepository？