問題タブ [domain-driven-design]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
orm - 結合テーブルに余分な列がある多対多マッピング
取得したいドメインは次のとおりです。
そして、これは私が持っているスキーマです:
これは不自然なスキーマとドメインですが、私が扱っているものとほとんど同じです。私は現在、CertificatesAcquiredByPeople テーブルを表す 3 番目のドメイン エンティティを作成することで機能していますが、それは本当に奇妙に思えます。
NHibernate を使用してこれをどのようにマップしますか? hbm ファイルのコンポーネント タグは、目的どおりに動作するはずですが、よくわかりません。
Certificate クラスに DateAcquired プロパティがあるため、私のドメインはおかしくなっていますか? 日付は、証明書を持っている人の関心事です。
[編集]
新しいエンティティが必要であることを反映するために、ドメイン モデルを変更しました。マッピングには 3 つの (エンティティごとに) マッピングが必要ですか、それとも 2 つ (個人と証明書の場合) で行うことができますか?
c# - データベースからドメインオブジェクトを作成するための迅速で正しい方法
データベースにユーザー、ユーザーグループなどの典型的なテーブルがあり、それらには関係があります。
私のドメインモデルでは、ユーザーをリクエストすると、ユーザーが取得され、各ユーザーが属しているプロパティを持っていることを望みます。つまり、これらは彼が属するグループです。プロパティで、グループのリストが必要です(グループとしてタイプセーフ)
一方、同じことを行う必要があります。つまり、各グループは、グループに属するユーザーを認識している必要があります。
私はこのクラスを持っています(例):
さて、それを実装する最良の方法と、すべてのオブジェクトを埋めるための最速の方法は何ですか。
ところで:私は亜音速を使用してすべてのデータベースレコードを取得しています(テーブルごとに1つ選択します)。少なくとも 1500 人のユーザーと 30 のグループがあります。
私の現在のコードは、グループのforeach、グループの関係.where、次にusers.singleordefaultに基づいてユーザーを見つけ、ユーザーをグループに追加し、グループをユーザーに追加します。ただし、これを行うには約30秒かかります。
私のclient-appはwebappなので、キャッシュされたリポジトリに結果を保存するので、このようにしています!!
domain-driven-design - Merging two domain objects
In the project I'm working on, we have an aggregate domain object. The factory object handles the creation of the unique id for the object. But there is a separate import process which creates the same object initially without the id. To add the imported object to the system, we are now forced to do a field by field copy to a new object since we can't just set the id for it for obvious reasons. Could anyone suggest a better way of handling this situation?
.net - DDD 境界コンテキストの特定とプロジェクトの構造化
私はドメイン駆動設計について頭を悩ませようとしています。私が見た例は理にかなっているように見えますが、特定の状況にそれらを適用する方法がまだわかりません.
ユーザーが記事を投稿/編集できる CMS を設計しています。これらは、コメントを作成したり、タグを追加したりできる他のユーザーが表示できます。私が持っている質問は、この状況での境界コンテキストは何ですか。ユーザーは、「コンテンツ作成者」または「コンテンツ ユーザー」として表示できます。
プロジェクト構造に関する限り、たとえば、Project.Data (モデル クラス)、Project.Services、Project.Repositories などを計画していました。これはすべて非常にデータ中心であり、それらが存在する境界付けられたコンテキストによってこれらを分割する必要があります。その場合、Article などの共有オブジェクトをどのように処理しますか?
新しい概念に頭を悩ませようとするときはいつものように、実際の状況に考えを適用しようとするまでは、例は完全に理にかなっています。
ポインタや有用なリンクは素晴らしいでしょう。
ありがとう、
c# - MVC とオブザーバーのパターン
プロジェクトに Observer パターンを実装する際に問題があります。プロジェクトは、Windows アプリケーションのように、C# で MVC として作成する必要があります。
私のドメイン モデルには、たとえば Country クラスと Country リポジトリがあります。すべての国 (フォーム上のリスト) を表示し、新しい国を追加し、既存の国を編集するための Country コントローラーとビューがあります。
国の変更に関連する変更について、どれだけのビューが知る必要があるかはわかりません。問題は、Observer パターンを使用する必要があることです。また、Web 上では、Subject が Country で、Observer が国を編集するフォームであり、すべての例がコンソール アプリケーションにある場合の例のみを見つけることができます。
国のリストを持つすべてのフォームが、既存の国を編集するだけでなく、新しい国を追加することを知っている必要があります。リポジトリをサブジェクトにする必要がありますか?
design-patterns - オブジェクトを作成するためにコンストラクターの代わりにファクトリを使用するためのしきい値は何ですか?
オブジェクトを作成するためにコンストラクターの代わりにファクトリを使用するためのしきい値は何ですか?
- あなたはいつも工場を使います。
- ヌルのチェック以外の不変チェックがある場合にのみ、ファクトリを使用します。
- 常にコンストラクターを使用します
- あなたはめったに工場を使いません...それらの場合は何ですか?
長所と短所
更新:プロジェクトにドメイン駆動設計のファクトリパターンを適用しています。また、ファクトリを作成する理由の1つは、ドメインモデルのノイズを減らすことです。
ありがとう
linq-to-sql - DDD、リポジトリ パターン、および関連するドメイン モデルとの闘い
私はこのようなもののいくつかに頭を包むのに本当に苦労しています。私が苦労している例を挙げましょう。
アプリの DAL として Linq-2-Sql を使用し、Rob Conery の MVC Storefront サンプル アプリで使用される IRepository パターンを使用しています。
私のドメインには、住所モデルのコレクションを持つ顧客モデルがあります。私の UI には、ユーザーが顧客に新しい住所を追加できるボタンがあります。これにより、住所エディターが開き、すべての情報を入力できます。
次は何が起こる?住所はデータベースに保存され、顧客オブジェクトのリストに追加されますか? リストに追加されるだけで、Customer オブジェクトが保存されるまで更新されませんか? ユーザーがアドレスを削除したい場合はどうすればよいですか? データベース内のアドレスを削除してから、リストから削除しますか? それとも、必要なすべての削除/追加を行うだけで、毎回データベースからすべてをダンプし、Customer.Addresses コレクションにあるもので更新しますか? ここで正しい流れは何ですか?
アドレスのコレクションは、次のような呼び出しによってリポジトリ経由でのみ更新される必要があります。
ヘルプ...
design-patterns - DDD - 値オブジェクト対。エンティティ オブジェクト
私は DDD が初めてで、いくつかの概念を理解しようと懸命に努力しています。ドメイン内でどのオブジェクトが Entity オブジェクトで、どのオブジェクトが Value オブジェクトであるかをどのように判断し、どのように正確に異なる扱いをするのでしょうか?
architecture - ドメインモデル-識別子の関係と階層オブジェクト
架空のドメインモデルを具体化する一方で、ドメインオブジェクトを関連付けるためのより良いアプローチは、親ドメインオブジェクトにポインタ(子の識別子)を含めることであるのか、それとも親オブジェクト内にコンポジットを構築するための子オブジェクト。
それぞれのアプローチの長所と短所、主にサイズと複雑さのトレードオフがわかります。遅延読み込みを行う必要性を予期していないため、識別子関係のアプローチに傾倒する傾向があります。
直接関連していませんが、ドメインオブジェクトは単純なPOCO(.NET-POJOと同等)です。最終的にアプリケーションドメイン間で交差する可能性が高いため、これらは明示的にシリアル化可能としてマークされます。私の意見では、LINQはリレーショナル識別子のアプローチを実行可能にします。LINQが利用できない場合は、まったく考慮しません。
どんな考えでもいただければ幸いです!
編集:識別子のみのアプローチに傾倒する可能性のあるいくつかの考え。まず、オブジェクトのキャッシュポリシーです。ポリシーで定義されているように、親オブジェクトと子オブジェクトのTTLが異なる可能性があります。2つ目は、再利用可能なデータの場合、同じ子が複数の親によって保持される可能性があるという点で、参照の保持によってオブジェクトの再利用が制限される可能性があることです。これらは両方とも、シリアル化されたオブジェクトの全体的なサイズにも関係しています。
domain-driven-design - Antlr は DSL ジェネレーターであり、意図的なプログラミングに代わるものですか?
最初は Microsoft で、次に彼自身の会社で、意図的プログラミングの分野を確立しようとする Charles Simonyi の努力の野心と創造性に私は感銘を受けました。
http://en.wikipedia.org/wiki/Intentional_programming
このソフトウェアへのアプローチでは、プログラマーはまず、特定の問題領域 (生命保険など) に固有のツールボックスを構築します。ドメインの専門家は、プログラマーの助けを借りて、WYSIWYG (What You See Is What You Get) のような方法で、プログラムの意図した動作を説明します。自動化されたシステムは、プログラム記述とツールボックスを使用して最終的なプログラムを生成します。連続した変更は、WYSIWYG レベルでのみ行われます。
これは、プログラミングに対する非常に有用で実用的なアプローチのようであり、現在のソフトウェア開発アプローチに伴う問題の多くを回避できる可能性があります。
基本的に、非プログラマー (ビジネス/システム アナリスト) によるドメイン固有言語の作成を容易にするように見えますが、UML が提供できるよりも実際の実装にはるかに近い段階にあります。最終的には完成するだろうが、まだ完成していない(ほぼ 15 年後)と彼は言う。
DSL は、単純な 5 行のルール エンジンから、Ruby on Rails のような複雑なアプリケーションまで、あらゆる範囲を実行します。したがって、彼の製品のリリースが遅れたのは、すべてのドメイン言語を一度にカプセル化できるようにする必要があるため、彼がはるかに高いレベルの抽象化を単純化することに取り組んでいるという事実に関係していると思います。
だから、私の質問は
(a) Antlrが意図的なプログラミングの代替になるかどうか - ビジネス アナリストが DSL を生成することを許可するのではなく、プログラマーの介入を必要とする、おそらくユーザーフレンドリーではない代替案ですが? Antlr を使用して、Ruby on Rails のような DSL を生成できますか (Ruby を出力としてサポートしていると仮定しますが、サポートされていないと思います)。できないことは何ですか?また、「言語ジェネレーター」ではなく「言語パーサー」と呼ばれる理由がわかりません。後者は使用目的を説明し、前者は最終結果をどのように達成するかを説明するためです。
と
(b) Antlr が意図的なプログラミングと異なる場合、意図的なプログラミングに似たものはありますか?