問題タブ [domain-data-modelling]

最初の警告: 長い投稿で、とにかくパターンが完全に間違っている可能性があります:

Customer Aggregate の開始である次のクラスがあるとします。

また、CustomerType は値オブジェクトで表されます。

CustomerTypeId を持つ顧客オブジェクトがある場合は、これで十分です。ただし、MVC ビュー内に DropDownList を設定する場合、ICustomerTypeRepostory から CustomerType 値リストを正しく取得する方法の概念に苦労しています。

はICustomerTypeRepository非常に簡単です。

基本的にはコントローラーから正しく呼び出せるようにしたいのですがICustomerTypeRepository、コントローラーからDAL（リポジトリ）レイヤーを分離するのが一番いいと思いました。さて、私は物事を過度に複雑にしていますか？

これが私のコントローラーの現在の状態です。

Controller と Customer にリポジトリがあるので、これは私には間違っているようです。CustomerType 用に分離されたアクセス レイヤーが必要であることは、私には論理的に思えます。すなわちCustomerType.GetList()：

では、オブジェクトを からに公開する方法はどれですか?CustomerTypeICustomerTypeRepositoryCustomerController

次のようなクラスを返すドメイン データ モデルがあります。

このデータをグリッドに戻すときは、データを常にフラットな形式でビューに返すのが最善であると読みました。したがって、グリッド行を表す次のクラスがあります。

したがって、これがレンダリングされるときはModel.Weapon、 の代わりに , を呼び出すだけですModel.FatalHit.Weapon。これにより、ビューのコードが読みやすくなりますが、マッピングが必要なため、明らかに追加の作業レイヤーになります。

これは本当に良い働き方なのか、それとも単に時間の無駄なのか?

私は貧血のドメインモデルで終わることを避けようとしているので、ドメインモデル自体の中で可能な限り多くのロジックを維持しようとしています。と呼ばれるメソッドがあります。これは、AggregateAddIngredientに新しいものを追加する必要があります。KeyedObjectRecipe

ドメインモデル自体にはリポジトリがないことを意図しているため、ビジネスルールクラスを介して要素を取得しています。

ご覧のとおり、ビジネスルールクラスServiceLocator.Factory.Resolve<GetIngredient>();を取得するために線を使用しています。次のような単純なコマンドハンドラです。GetIngredientGetIngredient

IoCファクトリクラスをに割り当てるServiceLocator.Factoryので、ドメインは具体的なクラスの実装を見ることなく、独自のインターフェイスを使用できます。

すべてが少しボッジのように感じられるので、私は何か間違ったことをしていると確信しています。

• 誰かが露骨に間違っているものを見つけることができますか？
• GetIngredientIoCファクトリへの静的参照なしなど、ビジネスルールハンドラをインスタンス化するためのより適切な方法はありますか？

技術文書に入れる必要のある非常に大きなモデルを生成しました。8000を超えるノードと32000を超えるリンクには適合しません。

スクリーンショットツールを試しましたが、領域全体を取得するために水平方向と垂直方向の両方ではなく、垂直方向のスクロールのみを実行します。

また、XPSとして保存してIEで開き、OneNoteにエクスポートしましたが、解像度が失われ、ノードが読み取れなくなりました。

この巨大なモデルを画像に取り込む方法について誰かアドバイスはありますか？

モデルを表示しているときに[ファイル]>[印刷]メニューが有効になっている場合は、PDFに印刷または画像に印刷できます。

編集：

4年後、私はまだこれに遭遇しています！今回はTIBCOモデルを使用しましたが、前回と比較すると、おそらく200分の1のように小さいです。

Java ModelinginColorのPartyPlaceThingとRoleの原型を使用しようとしています。

さらに、DDDのベストプラクティスを取り入れようとしています。ここで、アプリケーションに顧客と患者という2つの役割を演じる1人の担当者がいると仮定します。

CustomerロールはCRMBoundedContextで使用され、PatientロールはHospital ManagementBoundedContextで使用されます。

私のロールクラスは、弱いID、Personを一意に表すことができる値オブジェクトを使用して、Personの詳細にアクセスできます。このアプローチの詳細は、ここにあります。

現在、Party Place Thingの原型では、指定された責任の1つは、パーティーが果たしている役割をリストアップする機能です。

役割が異なる境界コンテキストに存在する場合、これをどのように達成しますか？

したがって、理想的には、顧客と患者は、人と同じ境界のコンテキストに存在するべきではありません

私は「定量的金融」でこの質問をしようとしましたが、取引よりもプログラミングに関する質問なので、これはより良い場所のようです

インターフェイスをどのように宣言しIndicatorますか？「インジケーター」をモデル化する正しい方法は何でしょうか？

私はc＃を使用しており、次Indicatorのようにインターフェイスを宣言したいと思います。

またはおそらくこのように：

私は「純粋な価格」も些細な指標と考えています。

MAの例：

どう思いますか？どんな提案でも大歓迎です！

アップデート：

私が探しているのは、クラスにゲッター/セッタープロップを追加するのではなく、各クラスを個別に作成する必要があるということです。つまり、次のことを意味します。

したがって、Visit を作成するには、VISIT に次の小道具が必要です。

または私はこれを持っている必要があります:

更新を終了

私が正しい方向に進んでいる場合は、アドバイス/フィードバックが必要です。以下はドメイン モデルです (完全ではないプロジェクトの一部です)。

その訪問モデルには「訪問」というクラスがあり、名前、目的、開始日、終了日などの訪問の基本があります...そしてそのクラスには、訪問を主催する人と訪問を要求する人もいます。

下のクラスについてどう思いますか？

}

[SO で現在活発に行われている同様の質問は、「関数型プログラミング パラダイムのビジュアル モデリング言語またはスタイルはありますか?」です。別の質問は関数型プログラミング パラダイムのみに焦点を当てており、私の質問はモデリング ツールを探しているため、この質問とは異なります。オブジェクト指向パラダイム (独立して確立されたビジュアル モデリング UML ツールが多数あります) と関数型プログラミング パラダイムの組み合わせをサポートします。

Scala プロファイルをサポートする (すべての Scala 言語アーティファクトを提供および含む)ビジュアル モデリング ツール/言語またはスタイルはありますか、またはオブジェクト指向プログラミング パラダイムと関数型プログラミング パラダイムを一緒にサポートすると言えます。

エンタープライズ規模の Scala プロジェクトの場合、ビジネス アナリストはどのモデリング ツールを使用して、論理 (概念) ビューおよび開発ビュー用のビジュアル モデルまたはその他のタイプのモデルを準備しますか?

• 論理ビューは、システムがエンドユーザーに提供する機能に関係しています。
• 開発ビューは、プログラマーの視点からシステムを示し、ソフトウェア管理に関係しています。

ソフトウェア開発の特定の分野では、正式なモデリングが必要条件になっています。プロジェクトの終了時には、さまざまなチームがさまざまなレベルで関与しており、関係者の多くはコードについて何も知りません。持つ必要はないし、求められたら大変なことになる。正式なモデリングは、彼らが開発で自分の役割を果たすことができるように、物事がどのように機能するかをよりよく理解できるようにするためにあります。(この段落はhttps://stackoverflow.com/users/166802/codnikから引用)

「債券」を処理する金融アプリケーションがあります。する必要がある

1. 貧血モデルを回避するためにアプリケーションをモデル化します (これは悪いことだと理解しています)。
2. 結合のタイプに応じて、さまざまな実装をインスタンス化します。

システムは外部システムから命令を取得し、その命令を指定された結合に適用します。したがって、私は命令エンティティを持っています

例えば、債券で可決された決議に「賛成」票を投じる指示の場合

および債券エンティティ

ただし、命令は通常、1 つ以上のことを行います (事実上、1 つの命令で多数の命令になります)。たとえば、前の命令をキャンセルする命令は、まず前のトランザクションをキャンセルし、次に特定の値を再計算する必要があることを意味します。また、単一の命令が過負荷になる可能性があります。これは、以前の命令をキャンセルしたり、解決策を投票したりするためです。

ドメイン サービスを使用して新しい命令を処理するように勧められました。

この構造で見られる問題は、メソッドが関連していなくても、命令ごとにすべてのメソッドが呼び出されることです。if ステートメントを使用することもできますが、コードが乱雑に見えます。

今、私の質問は、

1. これはモデル化するための最良の方法ですか？
2. また、計算については、債券の種類によって計算が異なります。だから私はポリモーフィズムを実装したい。ファクトリを使用して正しい実装をインスタンス化する必要があると言われました。これは最善のアプローチですか？

BondType 1,3,5 の場合、計算 A を使用し、bondType 2,7 の場合...計算 B を使用する必要があります。異なる計算タイプをインスタンス化するにはどうすればよいですか??? NB、私はポリモーフィズムに精通していますが、正しい実装をインスタンス化する方法の確かな例を見つけることができませんでした。ここまで読んでくれてthnx…

私は現在、集計内のエンティティ間の関連付けを処理するという問題に直面しています。

次の例を検討してください。

現在、私たちには ,,User" Entity があり、これは私の集約ルートでもあります。彼は、彼に関連付けられた ,,Product" を 1 つだけ持つことができ、多くの ,,Aliases" を持つことができます。私が現在必要としているのは、関連するものを取得する機能です。 ,,Product" および ,,Aliases" はドメイン モデル内でオンデマンドで作成されます。ユーザーは UserFactory によって作成されます。これは個別に使用することも、データからエンティティを永続的に作成するときに UserRepository 内で使用することもできます。

この理由は、ビジネス ロジック (例でわかるように) がオブジェクト間の関連付けに大きく依存しており、オブジェクト間の関連付けに関連するこのロジックはドメイン モデル内で実行する必要があるためです (または、これを移動する必要があるのではないでしょうか? )

次の解決策を検討しました。

1) User が構築されているときに、すべて (関連する Product と Aliases ) をロードするだけです。

長所：

• 動作しますか？

短所：

• 大きなパフォーマンスの問題 (残念ながら私はライブの高負荷システムに取り組んでいるので、これを見逃すことはできません)

2) リレーションシップ リポジトリをドメイン モデルに注入する

}

長所：

• 作品..

短所：

• DDD の目的を打ち負かす ( imo )。ユーザーはリポジトリを内部に持つ必要があります (そのため、ドメイン モデルは永続化に結び付けられます..)

3) 関連付け関連のロジックをドメイン モデルから委任します (おそらくドメイン サービスとポリシーに?)。

長所：

• また動作します

短所：

• 実際、これは貧血ドメインモデルにつながるように感じます.ビジネスロジックの大部分はオブジェクトの関係に基づいているため、多くのコードがドメインオブジェクトから移動され、意味がありません.

4) リレーションを処理するための特別な Relationship オブジェクトを作成します。

長所：

• また動作します

短所：

• 循環依存 ( User は UserProductRelationship を内部に持つ必要があり、それに依存しています。 UserProductRelationship は User エンティティと共に提供される必要があります。これら 2 つのクラスを組み合わせると、シナリオ #2 につながります)。

多分私は何かを正しく理解していませんでした..誰かが提案を持っているなら、私はそれについて聞いてうれしいです.

ありがとう！