問題タブ [invariants]

現在、DDD における不変式と検証に関する情報を消化しようとしています。私が正しく取得した場合、検証はドメインの問題ではなく、不変条件が発生しないように外部で行う必要があります。一方、ドメイン、特に集合体では、不変条件を適用する必要があります。

私を混乱させるのは、実際には2つのことです。

• ビジネス ルール (不変条件) を検証と区別する方法
• DRY原則を尊重する方法

詳しく説明しましょう。Tendersをカバーする Domain Model があるとします。2 つの主要なアクターは、入札プロセスの主催者 ( Organizer ) と入札プロセスの参加者 ( Participant ) です。主催者は、ステージの条件と要件に関する情報を含む入札公告を発行します (たとえば、最高価格の開始)。入札は、いくつかの段階からなるプロセスです。すべてのステージには条件があります。最初のステージは「入札の募集」です。この段階で、参加者はオファーを送信できます (提案）。

2 つの基本的な要件があります。

1. プロポーザル価格は開始上限価格よりも低くする必要があります
2. 参加者は、「入札の募集」段階でのみオファーを提出することができます

技術的には、次のように実装できます (詳細は省略します)。

上記のすべてを考慮すると、特定のコンテキストでの不変条件と検証の微妙な違いは何ですか? バリデータと集計でコードを複製する必要がありますか? (エンティティにバリデータを挿入したくありません)

どうもありがとうございました。

更新：

私は十分に明確ではなかったと思います。簡単に言うと、次の 2 つの点を考慮する必要があります。

1. ビジネス ルールと不変条件の違い。
2. SRP に違反する DRY に固執し、その逆も同様です。

最近、私と別の開発者が話し合い、次のような結論に達しました。

• 不変条件は、ビジネス ルールとは別に従わなければならないルールです。概念的には 2 つの異なるものですが、コードは同じかもしれません。
• このコンテキストでの DRY 原則は、SRP 原則に準拠するために違反する可能性があります。

私が間違っている場合は修正してください。

私はDaikon（おそらくプログラム不変検出器）を使用して、さまざまなメソッドを持つ単純なJavaクラスの不変式を生成しています。次のコマンドで達成したこのクラスからいくつかのメソッドを省略したかったのです。

このツールには、ENTER、EXIT などの特定のポイントで不変条件をスキップするオプションも用意されています。ここで、メソッドの EXIT ポイントをスキップしたいと考えています。コマンドに次のテキストを追加しましたが、うまくいきませんでした。

checkFirstAndLastValue():::EXIT

Daikons の出力から次のメソッドを省略する方法を教えてください。

C0.checkFirstAndLastValue(int, int):::EXIT

ありがとう。

私のプロジェクトは葉の形状認識です。Invariant Moments を使用して特徴抽出を行い、City Block Distance を使用してテスト画像とデータベース内の画像の間の距離を計算します。私が得る結果は非常に悪いです。認識は、一致の 50% 未満しか得られないと言えます。例えば：

これはテスト画像です

しかし、それはこの画像と一致します:

その画像を大津閾値を使って二値画像に変換するので、形が整った画像になります。私の質問は、これは正常ですか? または コーディングに誤りがありますか? これは、City Block Distance を使用した私のコーディングです。

そのコーディングで同じ画像を使用すると、結果は 0 値になりませんでした。なんで？ダブルデータ型だからですか？

添付のクラス図で、ローンを要求する人の年齢が 18 歳以上であることを示す不変条件を定義する必要がある場合、これは次のようになります。

また

2つの違いは何ですか？

ご指導ありがとうございました

ドメイン エンティティの検証ルールを追加する場所と、実装のベスト プラクティスに関するアドバイスを探しています。検索しましたが、探していたものが見つからなかったか、見逃していました。

プロパティが null でないこと、特定の範囲、または長さなどを検証するための推奨される方法を知りたい.エンティティが無効な状態になることはなく、前処理と後処理を使用することも、FluentValidation API を使用する他のエンティティも、不変条件が DRY と SRP にどのように影響するかを示します。

App Service、Bounded Context、Domain Service、Aggregate Root、Entity layering を使用する場合に、これらの種類のチェックを配置する場所の良い例を教えてください。これはどこに行き、最良のアプローチは何ですか?

ありがとう。

「Always-Valid」エンティティ アプローチ (後で isValid メソッドに対して) の支持者が、コレクションを使用してオブジェクトをモデル化することをどのように提案するかを知りたいです。このアプローチの背後にあるアイデアは本当に気に入っていますが、オブジェクトが少し複雑になるため、実装に苦労しています。すべてのフィールドを指定して、1 つの更新方法のみを使用するようユーザーに強制する必要があるのでしょうか?

例:

では、以下は、すべてのフィールドが指定された 1 つのコンストラクターと 1 つの更新メソッドのみをユーザーに提示する必要がありますか? それとも、複数のコンストラクターを使用する必要がありますか? 特定のプロパティ (オプション) をパブリック セッターに許可すると、一貫性が失われますか?

それとも、後で呼び出す必要がある isValid メソッドの使用を好むのでしょうか?

私の好みは、より安全に感じられるように不変チェックを行うことですが、すべてのプロパティをコンストラクターと更新メソッドの両方に追加する必要があるため、レイヤー間で呼び出すときや、オブジェクトのセットアップでさえ、処理が大幅に遅くなります。常に有効なクラスで構成されるコレクションは、これを悪化させます。