問題タブ [value-objects]

私はドメイン駆動開発から始めて、たくさん読んだ後、DDD の方法でアプリケーションをリファクタリングしようとしています。しかし、私は根本的な問題に直面しており、解決方法がわかりません。

導入として、私のアプリケーションが実行する必要がある単純化されたタスクをいくつか示します。コース予約アプリです：

• コースは、カテゴリ、日時、説明、および場所で構成されます
• カテゴリと場所はドロップダウン ボックスから選択できます
• 特別な設定セクションにより、ユーザーはカテゴリと場所を追加および変更できます

オブジェクトの不変状態について少し混乱しています。最初に、たとえば、lcoation はアイデンティティを持っているため、エンティティ オブジェクトでなければならないと考えました。しかしもちろん、場所自体は不変であり、変更することはできません。

私は本当に混乱しています。誰かが私の視界をクリアにするのを手伝ってくれますか?

現時点では、flags 列挙型を持つ Schoolyear というビジネス オブジェクトがあります。

私にとって、これは識別子のない値オブジェクトであり、余分な SQL テーブルを取得しません。これもやり過ぎでしょう。

ここで、これらの可視日 (ユーザーが構成できる) を int 値としてデータベースに保存することを考えました。現時点では機能しますが、データベースでの読み取り/書き込み、およびそれらの値のビジネスオブジェクトへの読み取り/書き込み、およびそのオブジェクトとの統合テストの実行は苦痛です。

JavaScriptクライアントがjsonデータを消費しているので、今朝、ブラウザから直接取得したjson配列をjson文字列としてデータベースに保存しないと思いました。したがって、私がしなければならない唯一のことは、クライアント側の json.parse です。サーバー側で統合テストを行うには、json ライブラリの既存の json.serialize/deserialize メソッドを使用します。

目に見える日は、年に1、2、または3回しか変更されません。ユーザーごとに、5 年間で 5 学年のデータ行があり、それ以上ではないかもしれません。可視日数列は、SQL 選択を介してクエリされることはありません。UI ロジックはクライアント側で行われます。

したがって、json配列をjson文字列としてsqlデータベースに保存することをお勧めします。

私の新しいアプローチについてどう思いますか? 後でもう一度悔い改めることができる、私が考えていなかったマイナスの副作用が見られますか.. ?

いくつかのテクニックを組み合わせて頭を悩ませようとしています。

有効でない ValueObject を作成できないようにすることは、良い習慣のようです。そのための ValueObject コンストラクターは、提供されたコンテンツが有効な ValueObject を作成するのに十分でない場合は常に失敗します。私が持っている例では、値が存在する場合にのみ EmailAddress オブジェクトを作成できます。ここまでは順調ですね。

提供された電子メールアドレスの値を検証すると、私は原則を疑い始めます。4 つの例がありますが、どれがベスト プラクティスと見なされるべきかわかりません。

例 1 は簡単なものです。構成関数、必須パラメーター「値」、およびコードをクリーンに保つための別個の関数 validate だけです。すべての検証コードはクラス内にとどまり、外部からは決して利用できません。このクラスの目的は 1 つだけです。メールアドレスを保存し、それが無効なアドレスにならないようにすることです。しかし、コードを再利用することはできません。コードを使用してオブジェクトを作成しますが、それだけです。

例 2 は、検証関数を静的関数にします。関数はクラスの状態を決して変更しないため、これは static キーワードの正しい使用法であり、その中のコードは、静的関数を埋め込んだクラスから作成されたインスタンスに何も変更することはできません。しかし、コードを再利用したい場合は、静的関数を呼び出すことができます。それでも、これは私には汚いと感じます。

例 3 では、オブジェクトの本体内にハードコーディングされた別のクラスを紹介しています。もう 1 つのクラスは、検証コードを含む検証クラスであり、検証クラスが必要なときにいつでもどこでも使用できるクラスを作成します。クラス自体はハードコードされています。これは、その検証クラスへの依存関係を作成することも意味します。これは常に近くにある必要があり、依存性注入によって注入されません。バリデーターをハードコーディングするのは、完全なコードをオブジェクトに埋め込むのと同じくらい悪いと言う人もいるかもしれませんが、その一方で、DI は重要であり、この方法では、新しいクラスを作成 (拡張または単に書き換え) する必要があります。依存関係を変更するだけです。

例 4 では、バリデーター クラスを再び使用していますが、それをコンストラクターに入れています。したがって、私の ValueObject は、クラスを作成する前に、すでに存在して作成されているバリデータークラスを必要としますが、バリデーターを簡単に上書きすることができます。しかし、単純な ValueObject クラスがコンストラクターにそのような依存関係を持つことはどれほど良いことでしょうか。本当に重要なのは値だけであるため、電子メールが正しい場合にどのように、どこで処理するかを知ることは私の関心事ではありません。正しいバリデーター。

私が考え始めた最後の例は、デフォルトのバリデーターを提供することであり、その間、DI を介してコンストラクターのバリデーターの上書きを挿入できるようにします。しかし、最も重要な部分である検証を上書きすると、単純な ValueObject がどれほど優れているか疑問に思うようになりました。

したがって、誰もがこのクラスをどのように記述するのが最善かという答えを持っています。それは、電子メールアドレスのような簡単なもの、またはバーコードやビザカードなどのより複雑なもの、または考えられるものすべてに対して正しいものであり、DDD に違反していません。 、DI、OOP、DRY、静的の間違った使用など...

完全なコード:

疎結合の OOP 設計に関する質問があります。Email のような単純な値オブジェクトがあるとします。

}

isValid メソッドを実際に実装するまでは、すべてが単純明快です。ここには2つのオプションがあります：

1）次のようなひどく醜いものになる可能性のある独自の検証ロジックを実装します。

2) 組み込みのフレームワーク バリデーターを使用する

車輪を再発明したくないし、コードを繰り返したくないので、最初の方法には従いたくないので、2番目の方法に固執しています。

2 番目の方法に従うと、問題が発生します。クラスが別のフレームワーク クラスに依存するようになります。

私の実際の質問は、単純なケースで依存性注入を使用せずに、エンティティ/値オブジェクトで低レベルのインフラストラクチャ クラスを直接使用することが許容されるかどうかです。

この例を「適切に」実装すると、疎結合のためだけに、コードがはるかに複雑になります。isValid 関数で使用される事前構成済みの EmailValidator のインスタンスを値オブジェクト (Email) クラスに提供する EmailFactory を作成する必要があります…</p>

私の販売モジュールにはクラスがOrderあり、そのクラスはいくつかの分類目標に使用し、s にいくつかのビジネス ルールを適用します。各クラスには独自のテーブルがあります。OrderTypeOrderTypeOrder

DDDプロジェクトにテクニックを適用したい。Orderでは、はAggregation rootだと思いますが、どうOrderTypeでしょうか? Order集計にも含まれていますか、それともValue オブジェクトですか? 価値ある物になると思います。私は正しいですか？

私は、大規模な従来の ASP Web アプリケーションをドメイン駆動設計の ASP.Net MVC に変換中です。私のドメインの多くは DDD に適していますが、純粋な DDD アプローチが適切でない状況に遭遇し続けています。たとえば、私のアプリケーションの読み取り側は、書き込み側とは大きく異なります。別の読み取りモデルを作成し、簡易バージョンの CQRS を実装しました (イベント ソーシングなし、別のデータベースなし)。もう 1 つの問題は、データベースの一括操作でした。問題ありません。それはサービスとして実装されています。ここに私の現在の困惑があります。私たちのシステムでは、ユーザーはシステムに変更を加えることができ、その変更は将来のある日付で有効になります。これに対応するために、発効日まで保留中の変更を保存するデータベース テーブルがあります。発効日に、自動化されたタスクが実行され、実際のデータベース更新が実行されます。更新タスクにはドメイン ロジックを含めることができるため、その部分は DDD に適合し、問題はありません。何が起こっているかを視覚化するために、保留中の更新を処理するクラスを次に示します。

ご覧のとおり、これはさまざまなデータベース テーブルの更新を処理できる汎用クラスです。基本的に、更新されているデータベース列、列の新しい値、列が属するテーブル、有効日、およびいくつかのログ データが格納されます。

ここに私の質問があります: 保留中の更新を収集して保留中の更新テーブルに格納するロジックは、ドメイン オブジェクトとしてモデル化する必要がありますか、それともサービスなどの他の方法で処理する必要がありますか?

別の言い方をすれば、PendingChanges 自体が独自のドメイン ロジックを持つドメイン エンティティなのでしょうか。変更が行われているエンティティとは別に、PendingChanges に適用されるビジネス ルールがいくつかあります。たとえば、UserArea を構成するものは、検証は言うまでもなく、FromTable の有効な値と同様にビジネス ルールと見なすことができます。

それとも、異なるドメイン オブジェクト間で再利用できるため、PendingChanges は値オブジェクトですか? その場合、PendingUpdatesService を使用する方が理にかなっていますか?