問題タブ [domain-model]

ドメインモデルのDDDセッターのコンテキストでは、コードの臭いがあります。それらは実際にはドメインの一部ではないという単純な理由で避ける必要があります。ドメインエキスパートが理解できる名詞は含まれておらず、データへの変更は代わりに特定の方法を使用する必要があります。

例：

そのための正しい方法はcustomer.ChangeAddress、イベントなどを公開できる方法を用意することです。少なくとも私の理解から、これはすべて健全な理論であり、ドメインモデルのセッターが本当に望ましくない理由を完全に理解できます。

しかし、ドメインモデルにセッターがないと、これらのメソッドのテストはかなり難しくなります。

すべての引数を受け取る大きなお尻のコンストラクターがない場合、またはリフレクションマジックを実行しない場合にテストを構築できない場合、Customerインスタンスを取得してテストを実行するにはどうすればよいですか？私はバックエンドでNHibernateを使用しているので、NHibernateは、そもそもこれらのフィールドにデータを入力するために、すでにいくつかのリフレクションマジックを実行しています。

しかし、10個の引数を持つctorがあるのは本当に気分が悪いです..（そして同じことがファクトリメソッドにも当てはまります）。

これについて何かアドバイスはありますか？

ダニエルの挨拶

ドメインモデルとデータモデルの違いは何ですか？

PersonオブジェクトまたはOrganizationオブジェクトのいずれかを含むClientオブジェクトがあります。これらのPersonオブジェクトまたはOrganizationオブジェクトは、 Clientオブジェクトとは独立した他のオブジェクトと関係がある場合があります。この場合、 Clientオブジェクトが全体である場所との間でGeneralAggregationアソシエーションを使用する必要があります。Client -> PersonClient -> Organization

次のシナリオにも注意してください。

1. 次のようなシナリオでは、人は通常の人である可能性があります。個人がクライアントに代わって支払いを行う（*組織*）
2. 人は、当社から製品を購入したクライアントである可能性があります。
3. 人はサプライヤーかもしれません

POCO を多対多の関係としてマッピングしようとしています。BehavioralEvents を含む Behavior のプロパティは必要ありません。多対多のマッピングは両方の場所にある必要があると確信していますが、Behavior クラスに対応するプロパティは必要ありません。

no-op アクセス演算子を使用できると聞きましたが、Fluent Nhibernate でそれを行う方法がわかりません。

お知らせ下さい：

Behavior クラス (BehavioralEvent への参照なし)

BehavioralEventClassMap:

BehaviorClassMap:

例えば：

10個のウィジェットを持つユーザーがいます。それに加えて、これらのウィジェットのうち 5 つを管理する Manager があります。

指定したマネージャーが管理しているユーザーのウィジェットを取得したいと考えています。そこで、WidgetMapper に fetchUsersManagedWidgets($userId, $managerId) という関数を作成しました。この関数は、これら 5 つのウィジェットのデータベースをクエリし、Widget オブジェクトの配列をマップします。

ドメイン オブジェクトがそのマッパーを認識する必要がないことはわかっていますが、WidgetMapper の関数を呼び出す User モデルで関数を作成できますか?

例えば

それとも、これは一方通行であり、ドメイン オブジェクトはマッパー関数を呼び出すべきではありませんか?

「ドメインモデルの継承は開発者の生活を複雑にしている」という議論が職場でありました。私は OO プログラマーなので、あちこちにスイッチを配置する代わりに、ドメイン モデルに継承を持たせることで実際に開発者の生活が楽になるという議論を探し始めました。

私が見たいのはこれです：

他の同僚が言っていることは次のとおりです。

この種の状況では、クラス階層の方が列挙型プロパティを使用するよりも優れていることを彼に納得させるにはどうすればよいでしょうか (リンクはWELCOMEです)。

ありがとう！

私たちは新しいプロジェクト (既存のアプリを書き直す) に取り組んでおり、ドメイン モデル / リポジトリの設計で問題が発生しています。

これは、ドメイン モデルの 2 つの重要な部分の (簡略化された) バージョンです。

ご覧のとおり、私はPostの抽象的な概念を持っています。これは、レビュー、ディスカッション、写真、ビデオなどのようなものです。投稿にはコメントを含めることもできます。

また、場所の抽象的な概念もあり、これは明らかに通り、都市、近隣などです。

さて、これは自然に私には 2 つの明確な集合根として見えました。

そこで、2 つのリポジトリを作成しました。1 つはPostRepositoryと呼ばれ、もう1 つはLocationRepositoryと呼ばれます。

これはすべて正常に機能していました。これら 2 つのリポジトリのいずれかを介して、任意のタイプの投稿 (またはコメント) を追加/取得し、任意のタイプの場所を追加/取得できます。

しかし、今は都市の「ランディング ページ」のシナリオにいます (たとえば)。

このページでは、基本的に「この場所のすべての投稿」を表示する必要があります。

それはどのように定義されていますか？まあ、投稿は（オプションで）場所でタグ付けできます。実装の詳細なので、データに深く入り込みたくはありませんが (それは DDD の目的ではないため)、基本的には、場所のシェープ ファイルによって特定の場所にどの投稿が含まれているかを判断するための地理空間インテリジェンスがあります。タグ付けされた投稿の緯度/経度。

しかし、境界を越えずにこの情報を取得するにはどうすればよいでしょうか?

どのリポジトリを使用しますか? 新しいものが必要ですか？

重要な場合 (または好奇心旺盛な場合)、これは SQL Server 2008 データベースと Entity Framework 4.0 を備えた Web アプリケーション (ASP.NET MVC) です。

説明が必要な場合はお知らせください。

編集

現在、ドメイン モデルを取得するために仕様パターンの修正版を使用しています。

たとえば、スコア >= 4 のすべてのレビューを取得する BLL のコードは次のとおりです。

しかし今、次のようなコードが必要です。

問題は、中間結合エンティティ (LocationPost - 多対多であるため) を追加せずに上記のクエリを実行する方法がわからず、それに Post ドメイン モデルに FK を追加することです。

でもそうする事で、私は総計の境界を越えていますね。

ドメインのモデルを設計するとき、ほとんどの場合、モデルにはいくつかの.IsSomething機能があります。 IsNewそしてIsDirty、データの永続化の目的、IsValidビジネスルールの検証、IsFraudulent現在のプロジェクト（より多くのビジネスルールの検証）などで一般的です。これらが他の人によって実装されているのを見ると、ほとんどの場合、メソッドとして実行されます。しかし、それには特別な理由があるのだろうかと思います。

私は、プロパティをオブジェクトを記述していると見なし、メソッドをある種のアクションを実行していると見なす傾向があります。これらは実際にはアクションを実行しません。呼び出されたときに動的に決定され、明らかに読み取り専用であるため、コードが含まれますが、私にとっては、メソッドではなくプロパティとして適合します。

プロパティにシリアル化の問題がある可能性があると思います。リッチドメインモデルは、ロジックと機能が含まれているため、とにかくシリアル化されない傾向があります。そのため、サービスの境界を越えて何かを移動する必要があるときは、通常、最初に定義済みのDTO構造にフラット化します。

しかし、他の誰かがこの主題について何か洞察を持っているのだろうか？これらをプロパティとしてではなくメソッドとして実装する正当な理由はありますか？

（正直に関連しますが、すでに答えが出ていますが、拡張プロパティはこのようなものの一貫性に本当に役立ちます。ドメイン固有のロジックを実装するためIsSomething()に、通常はにいくつかの拡張メソッドがあります。ただし、プロパティがSystem.String行く、私は拡張機能との一貫性のためだけにメソッドに固執したいかもしれません。）

最近いくつかのGregYoungビデオを見ていて、ドメインオブジェクトのセッターに対して否定的な態度がある理由を理解しようとしています。ドメインオブジェクトは、DDDのロジックで「重い」はずだと思いました。悪い例の良い例がオンラインにあり、それを修正する方法はありますか？どんな例や説明も良いです。これは、CQRS方式で保存されたイベントにのみ適用されますか、それともすべてのDDDに適用されますか？

問題：

asp.net mvc アプリの場合、ドメイン フォルダーを無視し、ドメイン モデルを別のライブラリ プロジェクトに記述します。

このようなライブラリ プロジェクトを使用する Visual Studio は、フォルダーごとに名前空間を作成します。たとえば、私のライブラリ プロジェクトが呼び出された場合:

ES.eLearning.ドメイン

Services というフォルダーがあり、Services フォルダー内のすべてのクラスの名前空間が次のように自動化されます。

ES.eLearning.Domain.Services

それはすべてうまくいっていますが、やり過ぎだと思います。私のプロジェクトは比較的単純なので、クラス名が衝突する可能性はありません。あったとしても、コンパイラはそれを拾います。

したがって、名前空間名をプロジェクト名に手動で編集するだけです。

ES.eLearning.ドメイン

そうすれば、フロント エンドを開発するとき、ドメイン モデル プロジェクトは、ドメイン モデルを提供するブラック ボックスにすぎません。また、名前空間を 1 つの機能ブロックとして扱うのではなく、名前空間の名前をプロジェクトのフォルダー構造に結合する意味がわかりません。

したがって、次の 2 つの疑問が生じます。

1. これは悪い習慣ですか？もしそうなら、なぜですか？覚えておいてください: これらは小規模から中規模のプロジェクトです。

2. 名前空間に名前を付ける方法を VS 2010 に伝える方法はありますか?

ありがとう

注: プロジェクトの命名では、ES はクライアント、eLearning はアプリ、ドメインはコンポーネントです。

PS：SOで見つけた名前空間の命名規則に関する他の質問は、さまざまな問題に対処しています。したがって、私が判断できる限り、重複していません。