問題タブ [anemic-domain-model]

私は、単一責任の原則をかなり真剣に受け止めているプロジェクトに参加しています。少人数制のクラスが多く、物事はとてもシンプルです。ただし、貧血ドメイン モデルがあります。どのモデル クラスにも動作はありません。それらは単なるプロパティ バッグです。これは私たちの設計に対する不満ではありません - 実際にはうまく機能しているようです

設計レビュー中に、新しい動作がシステムに追加されるたびに SRP が提示されるため、通常、新しい動作は新しいクラスになります。これにより、物事を非常に簡単に単体テストできますが、関連する場所から動作を引き離すように感じるので、時々当惑します。

SRP を適切に適用する方法についての理解を深めようとしています。SRP は、同じコンテキストを共有するビジネス モデリング動作を 1 つのオブジェクトに追加することに反対しているように思えます。そのオブジェクトは必然的に、複数の関連することを行うか、1 つのことを行うが形を変える複数のビジネス ルールを知っているためです。その出力の。

もしそうなら、最終結果はAnemic Domain Modelのように感じられます.これは確かに私たちのプロジェクトに当てはまります. しかし、Anemic Domain Model はアンチパターンです。

この 2 つの考えは共存できますか?

編集:コンテキスト関連のリンクのカップル:

SRP - http://www.objectmentor.com/resources/articles/srp.pdf
貧血ドメイン モデル - http://martinfowler.com/bliki/AnemicDomainModel.html

私は、預言者を見つけて、彼らの言うことを福音として従うのが好きなような開発者ではありません。したがって、「これがルールだ」と述べる方法としてこれらへのリンクを提供するのではなく、2 つの概念の定義のソースとして提供します。

SO でこのアンチパターンとそれに関する多くの懸念について読んだ後、再び混乱しています。

ドメイン モデルがあり、データ転送オブジェクトに永続化する必要があるデータをキャプチャする場合、ドメイン モデルはデータのラッパーになりますか? その場合、貧血ドメイン モデルを使用します。しかし、そのラッパーに十分なドメイン ロジックを追加すると、どの時点で実際のドメイン モデルになるのでしょうか?

ドメイン モデルで永続化する必要があるものをキャプチャすることは、優れたプラクティスに違反し、貧血ドメイン モデルのアンチパターンを作成するという印象を受けます。しかし、リレーショナル DB を使用する場合、オブジェクトの状態を構成する部分を特定して保存することを避ける方法はありません。

私は概念についてかなり混乱しているので、私が書いていることが意味をなすかどうかはわかりません. 気軽に質問してください。

アプリケーションが次のような場合、DDD とリッチ ドメイン モデルを使用することは可能ですか。

• Windows クライアント (WPF)
• Windows サービス

通信は WCF で行われますか?

私はデータ状態のみの DTO を使用し、サービス レイヤー内にビジネス ルールを設定することに慣れていますが、データ状態とルール/メソッドがすべてオブジェクト自体に含まれるリッチ ドメイン モデルが必要であると、誰もが言い続けています。

このリッチ ドメイン モデルが、UI を備え、WCF を介してサービスと通信するシステムに適用されるかどうかはわかりません (上記で説明したように)。私の場合、WCF のために貧血ドメイン モデルを使用し続ける方がよいでしょうか? そうでない場合は、WCF、プロキシなどを考慮して、リッチ ドメイン モデルを使用してアーキテクチャを構築する方法の例を教えてください。

ありがとう！

私たちの現在の O/RM ツールでは、実際には豊富なドメイン モデルが許可されていないため、あらゆる場所で貧血 (DTO) エンティティを使用せざるを得ません。これはうまくいきましたが、基本的なオブジェクトベースのビジネス ロジックと計算フィールドをどこに置くかについては引き続き苦労しています。

現在のレイヤー:

• プレゼンテーション
• サービス
• リポジトリ
• データ/エンティティ

私たちのリポジトリ層には、基本的なフェッチ/検証/保存ロジックのほとんどがありますが、サービス層はより複雑な検証と保存の多くを行います (保存操作はログ記録、権限のチェックなども行うため)。問題は、次のようなコードをどこに置くかです。

また

何かご意見は？

オブジェクト指向コードではなく手続き型コードを使用していることを示すのに役立つ指標はどれですか? 分析されたコードに、適切なオブジェクト指向の設計原則に従っているのではなく、手続き型のトランザクション スクリプトと貧弱なドメイン モデルが含まれている可能性が高いことを示す、単純なメトリックのセットが必要です。

測定に役立つ指標とツールのセットがあれば幸いです。

ありがとう、トーマス！

私は貧血ドメインモデルと、それらがおそらくアンチパターンである理由を理解しようとしています。

これが実際の例です。

名前、性別、ユーザー名など、たくさんのプロパティを持つEmployeeクラスがあります

次に、電話の着信とWebサイトの問い合わせ（「リード」と呼ばれる）を営業スタッフ間で均等にローテーションするシステムがあります。このシステムは、問い合わせのラウンドロビン、休日のチェック、従業員の好みなどを含むため、非常に複雑です。したがって、このシステムは現在、EmployeeLeadRotationServiceというサービスに分離されています。

次に、ウェブサイトのお問い合わせフォームの裏側に、次のようなコードがあります。

私はこのアプローチで実際に多くの問題に遭遇することはありませんが、おそらくこれは貧血ドメインモデルであるため、私が叫んで実行する必要があるものです。

しかし、私にとっては、リードローテーションサービスのロジックがどこに行くべきかは明確ではありません。それは先頭に立つべきですか？それは従業員に行くべきですか？

ローテーションサービスに必要なすべての注入されたリポジトリなどはどうですか？従業員を扱うときにほとんどの場合これらのリポジトリは必要ないことを考えると、それらはどのように従業員に注入されますか？

あなたの経験における貧血ドメインモデルの長所と短所は何ですか？ウィキが言っていることにもかかわらず。

更新：大規模なエンタープライズアプリケーションに適用されたこのパターンの経験に基づいた回答を求めています！

Entity Frameworkでは、フレームワークにDbContextを、コンテキストにアタッチされている、またはコンテキストから取得されている各オブジェクト（エンティティ）に挿入することはできますか？

私はNHibernateの人で、NHでも可能だと知っています。EFの世界でばかげた質問だとすみません。

基本的に、エンティティをコンテキストに関連付けるたびに、フレームワーク自体によってコンテキストのインスタンスに設定されるDbContextタイプのプロパティをエンティティの一部に持たせたいと思います。理想的には、そのようなクラスはIContextAwareマーカーインターフェイスなどでマークされます。

私がこれをやりたい理由は（=目標）です。今回は貧血ドメインモデルのアンチパターンを避けたいと思います。ObjectContextをエンティティに注入すると、DBにアクセスできるようになり、ドメインクラス自体の内部にクエリやより複雑なロジックを実装できるようになると思いました。私の目標を達成するための他の方法を知っている場合（特にWebアプリのコンテキストで）、そうしてください。ただし、「これを行うべきではない」などの回答は避けてください。ありがとう！！！

Java EEの世界での新しい改善により、大量のデザインパターンが廃止されたことを考えると、DTOは大部分が眉をひそめています。

ただし、データベースのリレーショナル構造によって、クライアント（Webアプリ）がEJBのサービスをどのように使用するかを決定する必要はありません。技術の進化のおかげで、光ファイバー技術やその他の考えられないことが現実のものとなり、UIのオーバーホールを試みるために約5年の間に作業が行われていると思います。したがって、ビジネスロジックを完全にカプセル化して、必要なときにいつでもUIを簡単に変更できるようにする必要があります。

この考え方を念頭に置いて、クライアントが代わりにそれを使用できるように、ビジネスモデルとサービスを表す純粋なAPIを開発しています。

ただし、エンティティBeanをこのAPIに変換するには、常にコンバーターを作成する必要があります。これは正しいことですか、それともエンジニアリングを超えていますか。

あなたのフィードバックと意見は大歓迎です。

NB。このプロジェクトは、完全なJavaEE6プラットフォームを使用します

私はここ 1 年ほど C# を学んでおり、その過程でベスト プラクティスを取り入れようとしています。StackOverflow と他の Web リソースの間で、懸念事項を適切に分離するための正しい軌道に乗っていると思っていましたが、今はいくつかの疑問があり、Web サイト全体をこの新しいものに変換する前に、正しい道を進んでいることを確認したいと考えています。建築。

現在の Web サイトは古い ASP VBscript であり、既存のデータベースは非常に醜い (外部キーなどがない) ため、少なくとも .NET の最初のバージョンでは使用したくなく、現時点で ORM ツールを学習する必要はありません。

UI レイヤーは DTO とビジネス レイヤーのみを表示でき、データ レイヤーはビジネス レイヤーからのみ表示できるように、個別の名前空間とセットアップにある次の項目があります。簡単な例を次に示します。

productDTO.cs

productBLL.cs

productDAL.cs

私の UI では、次のようにします。

保存の場合:

私は完全に基地から外れていますか？BLL にも同じプロパティを設定し、DTO を UI に戻さないようにする必要がありますか? 何が間違っていて何が正しいのか教えてください。私はまだ専門家ではないことに注意してください。

アーキテクチャにインターフェイスを実装したいのですが、その方法をまだ学んでいます。