15

データ フィールドとビジネス ロジックの両方を含む豊富なドメイン モデルを使用して、アプリケーションにドメイン駆動設計の原則を適用しようとしています。私は多くの DDD の本を読みましたが、それらのドメイン モデル (エンティティと呼ばれる) は非常に単純なようです。以下のような 10 ～ 15 個のデータ フィールドを持つドメイン モデルがある場合に問題になります。

class Job extends DomainModel{

    protected int id;
    protected User employer;
    protected string position;
    protected string industry;
    protected string requirements;    
    protected string responsibilities;    
    protected string benefits;
    protected int vacancy;
    protected Money salary;
    protected DateTime datePosted;
    protected DateTime dateStarting;
    protected Interval duration;   
    protected String status;
    protected float rating;  

    //business logic below 
}

ご覧のとおり、このドメイン モデルには多くのデータ フィールドが含まれており、それらはすべて重要であり、取り除くことはできません。優れたリッチ ドメイン モデルにはセッター メソッドを含めるべきではなく、そのデータをコンストラクターに渡し、ビジネス ロジックを使用して状態を変更する必要があることを私は知っています。ただし、上記のドメイン モデルの場合、コンストラクター メソッドで 15 以上のパラメーターが発生するため、すべてをコンストラクターに渡すことはできません。メソッドには 6 ～ 7 個を超えるパラメーターを含めるべきではありません。

では、大量のデータ フィールドを持つドメイン モデルを処理するにはどうすればよいでしょうか? 分解してみるかな。もしそうなら、どのように？あるいは、ビルダー クラスまたはリフレクションを使用して、インスタンス化時にそのプロパティを初期化し、コンストラクターを多くの引数で汚染しないようにする必要がありますか? 誰でもアドバイスできますか？ありがとう。

4

2 に答える 2

12

あなたが見逃しているのは、値オブジェクトの概念です。値オブジェクトは、それぞれのドメインで意味を持つ小さな不変オブジェクトです。

ドメインの詳細はわかりませんが、Jobエンティティを見るとJobDescription、次のような値オブジェクトがある可能性があります。

class JobDescription {
    public JobDescription(string position, string requirements, string responsibilities) {
        Position = position;
        Requirements = requirements;
        Responsibilities = responsibilities;
    }

    public string Position {get;}
    public string Requirements {get;}
    public string Responsibilities {get;}
}

これは C# のコードですが、使用している言語に関係なく、その考え方は明確であるべきだと思います。

基本的な考え方は、それぞれのドメインで意味のある方法で値をグループ化することです。これはもちろん、値オブジェクトに他の値オブジェクトを含めることもできることを意味します。

IEquatable<T>また、C# で実装するなどして、値オブジェクトが参照ではなく値で比較されるようにする必要があります。

このアプローチでコードをリファクタリングすると、エンティティのフィールドが少なくなるため、コンストラクター インジェクション (強くお勧めします) を使用することが再び実現可能になります。

質問に直接関係のないコード例に関する詳細なメモ:

  • ドメイン モデルは全体であり、エンティティはその一部です。したがって、基本クラスは呼び出されるべきであり、 ではEntityありませんDomainModel。

  • クラスのフィールドを作成し、カプセル化を維持するために必要なアクセサーprivateを提供する必要があります。protected

于 2015-10-12T08:15:49.227 に答える
2

ジョブ ドメイン モデル オブジェクトで非常に多くのことが行われています - 膨大な数の懸念事項が混在しているように見え、(少なくとも私には) 境界付けられたコンテキストがいくつか示唆されています。例。

  1. 報酬（給与、福利厚生）
  2. 組織上の地位（レポートライン）
  3. 人物スペック（スキル）
  4. 仕事内容（責任）
  5. 等

「Job」モデルと相互作用するものを検討する場合、たとえば、Salary プロパティと Industry プロパティの両方を検査または変更する必要があるものはありますか?

ドメインのニュアンスを完全に知らなければ、ポジションを保持することで得られる給与と、あなたが働いている業界は実際には関連していませんよね? 修辞的なポイントではありません。これらは、ドメインの専門家に尋ねる必要がある質問です。

それらに相互作用がない場合、これら 2 つのものが 2 つの異なる境界付けられたコンテキストに存在することが識別されます。Salary サイドは Industry サイドとやり取りする必要はありません。また、その逆も同様です。また、あったとしても、同じプロセスで同時に状態として保持する必要がありますか?

人が従業員になるまでのライフサイクルを考えてみてください。人が仕事に応募します。仕事には仕様、給与範囲があります。その人は面接に出席します。採用担当者はその人にポジションを提供します。その人は受け入れます。その人物は、もはや候補者ではなく従業員です。新しい従業員は現在、休暇と福利厚生を獲得しており、開始日などがあります。

DDD は、単一の統一された世界観が、どの懸念にも正しく役立つことはめったにないことを教えてくれます。BOUNDED CONTEXTS を調べてみてください。その結果、ソフトウェアはより柔軟で柔軟性のあるものになります。

于 2015-10-13T19:18:52.983 に答える