ディレクトリ
アウトライン
エンティティ-この記事では、他の一般的で非常に重要な概念ドメイン駆動設計（DDD）戦術的なモードを紹介します。（そのような値のオブジェクト、フィールドサービスなど）比較的少数の戦術モード他の概念は、エンティティは、比較的容易に理解して使用する必要があります。しかし、実体はそれ領域を見つけるためにどのように？どのように実体の設立はアクションが豊富であることを確認するには？それの詳細に注意を使用してそれらのエンティティが存在する場合は？この「実体」の概念についてのあなたの新しい理解をもたらすために様々な角度からの記事、および対応するコードの断片（このチュートリアルのコードスニペットを使用している与え、C＃ 、実際のプロジェクトの後半部分にも基づいて過去ログコアプラットフォームを）。
エンティティとは何ですか
国際的な慣行によると、の自慢をしましょう。直接オリジナルを見て、「ドメイン駆動設計：ソフトウェアの複雑道路のコアを対処」エンティティの解釈：
- エンティティ（も参照オブジェクトとして知られているエンティティ、）多くのオブジェクトは、その属性によって定義されますが、連続したイベントと定義されたアイデンティティの一連されていません。
- オブジェクト識別によって主として定義は、エンティティと呼ばれます。
この定義は理解できるものだったかのように2文以上、いくつかの回を読み取ります。前の記事とは異なり、DDDを使用する方法-値がオブジェクトので、難解な概念を。端的に言えば、上記の問題点を説明することで、限り、あなたは見つけたもの/オブジェクトは一意の識別子を持っているとして、それはおそらくエンティティです。我々はIDという高速な腐っを書くことに固有の識別コード。
デジャヴ
伝統的なデザインのアイデアと開発プロセスでは、我々はそれがどのような状況下で、オブジェクトとしてID与えられますについて考えるために、私たちはしていますか？これは、ID、それの影響を与えますか？一般的に私たちの目標は、それがデータベース内にある場合、このオブジェクトを区別するために、より多くの1以上は何も、ありません主キーとしてデータと、このセクションデータの別の一つであり、このIDを区別することであるとしばしば改善するには、2つ、プラスのインデックスは、あります関連スピードを探します。授業の形で提示したとき、我々は我々のコードにデータベーステーブルをマッピングするためにしている場合、それはおそらく次のようになります。
//旅行的行程
public class Itinerary
{
public int ID { get; set; }
//参加本次旅行的人员
public List<Person> Participants { get; set; }
//旅行的地点
public List<string> Places { get; set; }
//关于该行程的备注笔记信息
public string Note { get; set; }
//旅行开始时间
public DateTime StartTime { get; set; }
//旅行开始时间
public DateTime? EndTime { get; set; }
//旅行的状态(进行中 or 已完成)
public int Status { get; set; }
}上記のコードは、私たちは不慣れいけないためにした、私たちは旅のプランニングを選択理由として、個々のブログがケースとして注文ああ、電子ビジネスプラットフォームに表示されていない、クラスの旅程を確立しています。旅行記を実装するために一緒に、後の手の中に私たちがするので、小さなプログラムを微信、そして私たちはゆっくりと私たち自身のドメイン駆動のフレームワークを開発するための基礎としてDDD理論に学んだの援助は、当然のことながら、このプロジェクトにも基づいていることを過去ログコア（バージョンが3.xのでなければなりません）。
さて、あるいは我々の例に戻ると、IDの現れの目的について考えます。あなたは言うかもしれない：「これは何年もの間、シンプルでありながら、老婦人のクロスバ・ソースの世界ではありません、あなたはまだ、この質問のIDが道を区別するために使用しなければならない何千もの旅行何百もの私に尋ねる、私は間違いなくこのストローク見つけるだろう！このIDああを必要としています。「はい、これは議論の余地のない問題です。私たちは、オブジェクト間の違いを区別するための一意のIDが必要です。この資料の冒頭にも実体はほとんどの人が理解し、他の戦術的な概念に関連し得ることを言ったので、これは、同じ目的を持つ事業体における私たちのクラスID DDDと接触して通常です。
あなたが本当にIDが必要であることを確信しています
上の私たちの記事を覚えておいてくださいDDDを使用する方法を-値はオブジェクトあなたが言及したような問題は？「オブジェクトの現在のコンテキスト値は、別のエンティティのコンテキストであってもよいです。」だから、あなたは現在決定しなければならない企業が環境（コンテキスト）の現在のフィールドに基づいていなければなりません。環境を去った後、すべてが変数になります。現在の環境で同一のもの（オブジェクト）は、それを識別するための一意の識別子を必要とし、一意には意味のない識別することができる別の環境では、エンティティが目標値になる可能性があります。次の例を考えてみます。
銀行業務アプリケーションでは、顧客が自分の銀行口座に$ 10置くことができます。彼女は未来が、彼女は銀行に彼女のお金に比べて、$ 100抽出された1日は、彼女は別の法案やコインを受け取ることができます。お金だけの価値に関心のある顧客、資金のアイデンティティが重要ではないので、この違いは、無関係です。したがって、この分野では、資金調達は間違いなく値オブジェクトです。しかし、このような生産など他の分野、または紙幣のトレーサビリティ業界を印刷する紙幣を含む、個々の紙幣や硬貨のアイデンティティが実際に重要な概念かもしれフィールドです。だから、各ノートは、固有のエンティティ識別子いるだろう
アプリケーションの実体
オブジェクトの合成値
独自の固有の識別IDに加えて、多分そこには属性という多くのものがあり、これらのものは、を使用してになる傾向があり、内部実体：我々は、オブジェクトの値を学んだ最後の章を忘れてはいけませんオブジェクトの値が特定されます。
次に、上記の書き換えで見てみましょう旅程のカテゴリ：
public class Itinerary
{
public int ID { get; set; }
public List<Person> Participants { get; set; }
public List<Address> Places { get; set; }
public ItineraryNote Note { get; set; }
public ItineraryTime TripTime { get; set; }
public ItineraryStatus Status { get; set; }
}
public class ItineraryNote
{
public string Content { get; set; }
public DateTime NoteTime { get; set; }
public ItineraryNote(string content)
{
Content = content;
NoteTime = DateTime.Now;
}
}その動作指定されたエンティティ
オブジェクトが設定されている場合は、私たちのビジネス・ロジック処理を実現するために、我々は、インスタンス化されたオブジェクトを操作する必要があります。今、私たちは、システムの最初の要件を提案する：ユーザーが発言情報の旅程を変更することができます。
我々はそれを行うだろうか、この操作に対処する必要がある場合は、バックのコードの私たちの初版に行きますか？
itineraryInstance.Note =「これが私の新しいノート情報です」。
オブジェクトをインスタンス化するために割り当てられた値は、この上記のようにされていないで、あなたはそれを追加する必要があります。この操作は、我々は今、プログラミングの練習に行っている、それはより正常です。
場合は、「備考情報」の多様なニーズを持つ私たちのプロジェクトはそれに対処することを考えなければならない、我々はそう。プロパティの変更がコードに散在されます。私たちは、このような私たちが追加する必要があり、この時のように、要件の強化検証を持っていたときと：情報を変更するユーザーは、トリップ時間備考、ユーザーのみが200語以内のテキストを入力することができます。OMG、今回はすべての散乱の断片を発見し、彼のために検証を追加する必要があります。
別の観点から、クラス我々のビルドの最初のバージョンは、我々は唯一の旅行日程に関連する業務について読むことができるようになり、それ自体でそれを見ることができない、我々はそれは一方で、開始時間、メモやその他の情報を持っていることを知っていますそれらが相互作用する方法を知る方法はありません。
そのため、このクラスは、属性のみしている、またはPOCOは我々が呼んで、提示を入力し、「貧血モデル」。
次に、我々は、コードの第二版に戻って、我々はそれが行動がそれに属し与えます。我々は、需要から学んだ旅程を変更することができる情報を指摘し、情報がそう旅行自体に属している必要が変化挙動に発言情報の変更、旅行の一部である発言します。私たちは、少しのコードを変更します。
public class Itinerary
{
public int ID { get; set; }
public List<Person> Participants { get; set; }
public List<Address> Places { get; set; }
public ItineraryNote Note { get; set; }
public ItineraryTime TripTime { get; set; }
public ItineraryStatus Status { get; set; }
//ctor
public void ChangeNote(string content)
{
if(content.Length > 200 )
throw new NoteIsOverlengthException();
Note = new ItineraryNote(content);
}
}
この時点で旅程が与えChangeNoteを事業を許可し、ときの行動、変更のメモに外の世界のニーズ、単純にどちらかの方法の変更を呼び出すことによって、しかし、あなたがこれらを読むために他の開発者を展開すると、明確に理解しますNotesユーザーは200語以下を変更します。
しかし、我々はまだ軟膏でハエを持って、私はあなたにも見つけるかもしれないと思った：プロパティおよび外部に露出します！はい、それは外の世界に変更することが、我々はまた、無料の、クラスのクラス公開振る舞いを変更することによって、私たち自身の特性に加えて、と言うことです。これは明らかに心の中で私たちのデザインを満たしていません。だから我々は、民営化のすべての属性を設定することができます。したがって、私たちは「ことを知ってください、私たちは、エンティティを検討することに注意しなければならない凝集および高度の自治内のエンティティ」（強調はノック!!!!!）。
もちろん、一部の開発者は、そうエンティティの完全自律性は、プロパティに上記のコードは、すべてのプライベートフィールドに変換することを外の世界だけ公共団体行動によって処理することができ、別の文言をしようとします。
public class Itinerary
{
public int ID { get; set; }
private List<Person> participants;
private List<Address> places;
private ItineraryNote note;
private ItineraryTime tripTime;
private ItineraryStatus status;
//ctor
public void ChangeNote(string content)
{
if(content.Length > 200 )
throw new NoteIsOverlengthException();
note = new ItineraryNote(content);
}
}しかし、時に外の世界のエンティティの値を取得する必要があり、またはあなたがORMマッピングを必要とする非常に友好的ではないかもしれませんが、似たように使用できるメモモードに対処するためのスナップショット方式。後期我々はいくつかの例を達成するために、このモデルを採用します。
エンティティによって設立され、我々は呼んでそのアプリケーションの動作実体配る「混雑モデルを。」だから、貧血モデル良いか混雑モデルが良いですか？多くの学生は確かにあなたを依頼する必要があり、言うと、確かに混雑モデルの友人です。実際には、この答えは、使用混雑するために、モデルとブラインドは、いくつかのエンティティに属していないようならば、我々はゆっくり（おそらく、この分野の専門家と通信することにより）、達成可能な領域の分析を通じて、企業の自己の行動を本当の答えを持っていませんそれに割り当てられた動作は、唯一のエンティティは、より混沌と良いよりも、より害になりようになります。したがって、このモデルでは、貧血は、貧血のモデル、それは常に自分自身の行動を豊かに属していてもよい被写界深度と後者となっていることを意味するものではありません。
いくつかの値のオブジェクトを転送しようとする行動
それは、これは簡単には罠に落ちたとき、彼らは一緒に関連する行動の数を引かされるということです----肥大化になってからそれらを防ぐことができますので、責任が重要であることを、エンティティのアイデンティティに焦点をおいてください。このフォーカスを達成するためにオブジェクト関連行動およびサービスエリア（サービスエリアはまた、記事の後半に導入される）の値に委託する必要があります。
コードの最新バージョンを検討するために、我々は行動分割する必要があり旅程を、しかしよく見ると、私たちは、このルール我々は値オブジェクトに転送することができ、需要の増加後半に検証ルールを追加しましたか？答えは私ができる、です。ノートの有効性は、この行為に属している必要があるため、転送は、多くの場合、独自の必要です。マシンの起動時に自己効力感と同様に、この動作は、オペレータまたは機械自身の一部ですか？
我々は、転送値オブジェクトの振る舞いの一部に来るよう、最適化されたコードは次のようになります。
public class Itinerary
{
public int ID { get; set; }
public List<Person> Participants { get; set; }
public List<Address> Places { get; set; }
public ItineraryNote Note { get; set; }
public ItineraryTime TripTime { get; set; }
public ItineraryStatus Status { get; set; }
//ctor
public void ChangeNote(string content)
{
Note = new ItineraryNote(content);
}
}
public class ItineraryNote
{
public string Content { get; set; }
public DateTime NoteTime { get; set; }
public ItineraryNote(string content)
{
if(content.Length > 200 )
throw new NoteIsOverlengthException();
Content = content;
NoteTime = DateTime.Now;
}
}ビジョンは美しい現実は残酷です
ここで、私たちは本当に順風満帆であるように見える：自分自身のエンティティの確立、およびオブジェクトの値のいくつかのブレンドは、エンティティの行動は非常に彼らに集まった範囲内です。それは私たちが直接DDDがそれを上陸できることではないでしょうか？申し訳ありませんが、ちょうど字幕として、のような、現実は本当に非常に残酷です。あなただけのコードとビジネスプロセスから読み込まれた場合、我々は確かしかし、成功であったかもしれません！！！私たちは、永続的である我々のデータを保存する必要があります。エンティティが値オブジェクトの多くが含まれているため、オブジェクトの永続性の問題が直面しているすべての値は、それが二重にするためにさらに困難に遭遇します！オブジェクトの永続化の難しさの値についての記事を参照することができDDDを使用する方法-値オブジェクト。
私たちは、属性（参加者、場所）の2セットを持って、コードの最後の版で振り返ります。単一値のオブジェクト永続化、それは私たちに頭痛を与えている、と今、私たちは、オブジェクトのコレクションの価値の持続的な問題に直面しています。EFコアORMフレームワークを使用して、あなたが永続操作のこの種を行うようにした場合、あなたは私たちがリスト内のオブジェクトの値にIDを追加する必要があることがわかります、そのオブジェクトの値は明らかに実体となっている一意の識別子を持っていますこれは非常に怖いものです。私たちは、実際に変更になる最後のステップの着地でビルドドメインモデルに懸命に働いたが、これは多くの場合、再構築フィールド、絶えず中断されるドメインモデルで、その結果、ORMフレームワークやリレーショナルデータベースによって制限され、DDDの着陸が難しい重要な理由でありますモデルは、最終的には、従来の3層アーキテクチャまたは指向データベースのモデリングに戻って書いた、より多くのグロテスクになります。
しかし、少なくとも今のところ、彼らは慎重に検討、見ていたものを信じて、見つかったあなたが持っているオブジェクトとエンティティの分野でのプロジェクトの値は、我々が開発者に勇気を持つべき理由である、なぜなら、永続的な問題を知っているとあきらめて妥協しないこと。今後の記事では、我々は多くの問題と、問題の持続性はもちろん含めたソリューションを、提案対象エンティティの値になります。
概要
本論文では、私たちの前に心の中で人々を保つため、実際のコードを使用する方法エンティティに関連した経験実体と実体の概念を導入します。たとえば、「実体は、環境の現在のフィールドに基づいていなければならない（文脈）の」、 「実体をポリの高さの範囲内そして、自律性は、「」、エンティティの行動ではなく、データに焦点を当て、「すべきであるというように。今後の記事は検討事項のサービスの一部としてだけでなく、すべてのコンテンツ領域のためのエンティティと値オブジェクトをもたらすでしょう。