問題タブ [anemic-domain-model]

オブジェクトの構築に使用するデータ行の主キーを渡すことにより、データベース テーブルのデータを使用してオブジェクトを構築しています。

このオブジェクトのメンバー変数の作成は、コンストラクターまたはコンストラクターによって呼び出される別のメソッドで行う必要がありますか、それともまったく別の場所で行う必要がありますか?

Rails ActiveRecord やその他の ORM でこれを行うにはどうすればよいですか。フレームワークによって各フィールドに対して呼び出されるセッターのセットがあると思われますが、複雑なフレームワークでこれらすべてを実行する必要はありません。独自のシンプルなメカニズム？

注：自分の状態を管理できない大量の貧血データモデルを作成したくないことに注意してください。

初めての CRUD アプリケーションを作成しようとしていますが、getter と setter が分離されたオブジェクトを使用する必要があるかどうかわかりません。

以下を含むモデル構造を持つZend Framework クイック スタート チュートリアルがあるとします。

• ゲートウェイ
• データマッパー
• ドメイン オブジェクト (モデル クラス)

ドメイン オブジェクト (Zend クイック スタート チュートリアルに示されている) がゲッターとセッターのみで構成されている場合、それはアンチパターンですか? ある意味、トランザクション スクリプトでドメイン オブジェクトを不必要に分割しているのでしょうか。

お知らせ下さい。

これが重複している場合は申し訳ありませんが、関連する質問でトピックに関する具体的な例を見つけることができませんでした.

「Anemic Domain Model」に関する Martin Fowler の記事を読んだ後、なぜこれがアンチパターンと見なされるのか疑問に思いました。私の知る限り、j2ee アプリケーションの 90% は「貧弱な」方法で設計されているため、大多数のエンタープライズ開発者はそれをアンチパターンと考えていますか?

誰かがこのトピックについてさらに読むことをお勧めできますか (「ドメイン駆動設計」の本以外)、またはさらに良いことに、このアンチパターンがアプリケーションの設計にどのように悪い影響を与えているかについて具体的な例を挙げてください。

ありがとう、

私が直面している問題の簡単な例を次に示します。これは、ここで提示されているアイデアの一部や、DDD に関する他の場所と一致していません。

人を作成/操作する ASP.NET MVC 3 サイトがあるとします。コントローラーはアプリケーション サービス レイヤー (PersonService) にアクセスし、ドメイン エンティティ (EF 4 POCO) と PersonRepository を使用して変更を行い、それらを永続化します。簡単にするために、ここではすべてのインターフェイスを省略しています。この場合、Person がルートであり、簡単にするために電子メール アドレスのみを持ちます (また、電子メールは不変ではなく、更新できると仮定します)。

オプション 1: エンティティに直接関連する動作がエンティティの一部として実装される DDD の基本 [私の理解] に固執するようにしてください (Person は AddEmail、ChangeEmail などを実装します)。これに関する唯一の問題は、Add* メソッドを除いて、Person がコンテキストまたはエンティティ フレームワークの部分について知る必要があること (これにより永続性の無視が取り除かれます)、または「サービス」またはリポジトリを使用してマークを付ける必要があることです。変更されたメール。

オプション 2: 個人サービスでリポジトリを使用して電子メール アドレスを追加/更新し、個人エンティティに動作を実装しないようにします。これは、多対多の関係 (作業を完了するために 2 つのテーブルを更新する必要があるアドレスなど) の場合ははるかに単純ですが、その場合、モデルは単なる getter と setter の集まりである「貧血」になります。

とにかく、これについて何か考えはありますか？

ありがとう、ブライアン

貧血ドメイン モデルを回避するためにどの程度注意を払う必要があるかについて、アドバイスを求めています。私たちは DDD を始めたばかりで、単純な設計上の決定に関する分析麻痺に苦しんでいます。私たちがこだわっている最新のポイントは、特定のビジネス ロジックが属する場所です。たとえば、Orderオブジェクトなどのプロパティがあります。たとえば、誰かが注文を間違えたために次のStatusようなコマンドを実行する必要があるとします。これはそれほど単純ではありません。UndoLastStatusを変更するだけでStatus、他の情報をログに記録し、プロパティを変更する必要があります。現実の世界では、これは純粋な管理タスクです。したがって、私が考える方法には、考えられる2つのオプションがあります。

• オプション 1: メソッドを order に追加して、 のようOrder.UndoLastStatus()にします。これは理にかなっていますが、実際にはドメインを反映していません。またOrder、システムの主要なオブジェクトであり、注文に関連するすべてが注文クラスに配置されると、手に負えなくなる可能性があります。

• オプション 2:Shopオブジェクトを作成し、さまざまな役割を表すさまざまなサービスを使用します。だから私は、、、およびを持っているかもしれShop.AdminServiceませShop.DispatchServiceんShop.InventoryService。したがって、この場合、私はShop.AdminService.UndoLastStatus(Order).

2 番目のオプションは、ドメインをより反映したものであり、開発者は実際に存在する同様の役割についてビジネスの専門家と話すことができます。しかし、それはまた貧血モデルに向かっています. 一般的には、どちらがより良い方法でしょうか?

以下は、JPA注釈付きの型階層であり、すべてのデータフィールド（および関連するゲッターとセッター）は、ビジネスロジックを実装するための抽象的なメソッドとともにスーパータイプのメンバーです。データメンバーを追加せずにこれらの抽象メソッドを実装するサブタイプはいくつもあります。したがって、単一テーブル継承戦略を使用して、このタイプ階層をバックアップするためにデータベース内の1つのテーブルのみが必要になります。

データの内容に基づいて、最終的な目標を達成するために実装する必要のあるさまざまな動作があるため、このようにしました。

これは、JPA / Hibernateのディスクリミネーター列の概念の転覆ですか？

同僚は、データの構造はサブタイプごとに変化しないため、抽象メソッドと対応する実装を戦略パターンアプローチのようなものに移行する必要があると主張しています。彼の考えは良いですか？

最近読んでいて、Martin Fowler の Anemic Domain Model に関するこの記事に出くわしました。私は知っています、それは古いですが、どういうわけかJavaの世界では非常に現実的です. そのため、よりドメイン主導の設計に移行しようとしています。1 つのオプションは、Active Record モデルを使用することです。ただし、Scala での現在の実装はあまり好きではありません。ドメイン オブジェクトを永続化タイプと完全に結合します (ほとんどの場合、それほど悪くはありませんが、RDB と Mongo の両方に何かを格納する必要があるプロジェクトがあります)。次に、Spring、Hibernate、および Scala に関するこの記事に出くわしました。ここでもドメイン オブジェクトが JPA トレイトと結合されていますが、Spring を使用して通知サービスを注入する方法に気付きました。同じメカニズムを使用して、透過的な DAO インターフェイスを挿入することはできませんか? これがどこかで使われているのを見たことがありますか？アイデアについて何か考えはありますか？

例によってドメイン駆動設計を学ぼうとしていますが、アドバイスが必要です。Tender というエンティティがあるとします。外部サービスから SOAP メッセージを受信しました。メッセージには入札に関するすべての情報が含まれています(tenderId、tenderSum、...)

私がしなければならないこと：

1. Soap Web Service でメッセージを受信し、メッセージをメッセージ キューに入れる - Serviceによって行われる
2. キューからメッセージを取得 -サービスによって実行
3. Database に移動し、tenderId で Tender オブジェクトを取得するか、新しい Tender を作成します -リポジトリで行います
4. Tender オブジェクトのフィールドに Message からの値を入力します - Domain Object Tenderによって行われます
5. 入札をデータベースに保存 -リポジトリで実行

正しい方法で実行しようとしましたが、最終的に、ほとんどのコードがサービス、リポジトリなどに存在することがわかりました。本当に混乱しています。私は何を間違えましたか？ドメインオブジェクト内でこれらすべてを行う必要がありますか?

私のシステムでは、ユーザーは任意の数の旅行を公開できます。Miユーザークラス（ドメインオブジェクト）はこんな感じ

したがって、id = 1のユーザーのすべての旅行を取得したい場合：

それは機能しますが、私のUserクラスは「貧血ドメインの問題」（または貧血のPOJOの問題、存在しますか？）に苦しんでいると思います：プライベートフィールドと「getters」と「setters」だけがあります（そして私のPOJOはすべて同じです）。

私は別のアプローチを考えました：

と

この2番目のアプローチでは、Userクラスにはより多くの機能がありますが、トリップはデータベースに保存されません。

私は何かが足りないのですか？私はDAOの初心者ですが、正しいアプローチを取っているかどうかわかりません。

ありがとう（ええ、私の英語は最悪です）。

トランザクション スクリプト (サービス層) アーキテクチャの代わりにドメイン モデル アーキテクチャを使用する ASP.NET MVC のオープン ソース プロジェクトはありますか? 小さな例ではなく、プロジェクトの詳細を探しています。