ディレクトリ
ドメイン駆動設計 - ライフサイクルのオブジェクト
各オブジェクトは、図6-1に示したライフサイクルを有しています。オブジェクトが作成されているので、それが最終的に消滅するまで、異なる種々の状態を経験すること - アーカイブまたは削除のどちらか。もちろん、多くのオブジェクトはガベージコレクタによって回収され、その後、簡単な一時的なだけでいくつかの計算を行うには、コンストラクタを呼び出すことによって作成されたオブジェクト、およびです。このようなオブジェクトは、複雑なことをする必要はありません。しかし、いくつかのオブジェクトがアクティブなメモリに費やされた時間の一部ではない長いライフサイクルを、持っています。彼らは、他のオブジェクトとの複雑な相互依存性を持っています。彼らは、いくつかの固定のルールを遵守するための変更時の状態のいくつかの変化を経験します。これらのオブジェクトを管理するときの顔多くの課題は、わずかなミスがモデル駆動型DESIGNトラックを外れます。
次のカテゴリ内の主な課題。
（1）ライフサイクル全体の整合性を維持します。
（2）は、それらに起因する問題を抱えたライフサイクル管理の複雑さからモデルを防ぎます。
（重合）にAGGREGATEは、それが明確な境界や所属によって定義され、凝集モデルを実現するために、オブジェクトの複雑なネットワークを混乱を避けるために。集約モードは、ライフサイクルの様々な段階の整合性を維持する上で重要な役割を持っています。私たちは、彼らの内部構造をカプセル化するために、複雑なオブジェクトとAGGREGATE（重合）を作成し、再構築するためにFACTORY（ファクトリー）を使用して、ライフサイクルの先頭に注意を向けます。最後に、中央のリポジトリ（リポジトリ）とライフサイクルの終了検索を提供し、永続オブジェクトとパッケージ化手段巨大なインフラを取得します。
リポジトリとFACTORY自体にもかかわらず、それがフィールドに由来していないが、彼らはデザインの分野で重要な役割を果たしています。これらの構造は、簡単に把握オブジェクトモデルのアプローチ、より完全なモデル駆動型設計を提供します。
AGGREGATEは、我々は、細胞を検出するために、オブジェクトのライフサイクル全体をモデル化することができるようにすることを、FACTORYリポジトリを使用し、設計に組み込まれ、モデリングを使用して、彼らがシステムを操作します。AGGREGATEは、その固定されたルールを維持しなければならないライフサイクルのすべての段階で、この範囲内のモデル要素の範囲に分割することができます。FACTORYとリポジトリAGGREGATEは、カプセル化された変換された複合体の特定のライフサイクルに基づいて動作します。
集計
関連する設計オブジェクト間の簡素化トラバースを助け、ある程度急激な増加の関係を制限を減らします。しかし、オブジェクトのほとんどの事業分野は、最終的に長く、深いオブジェクトの参照パスにつながる非常に複雑な関係を持って、我々はこのパス上のオブジェクトを追跡する必要があります。一部では、この混乱は非常にいくつかの明確な境界ので、現実の世界、現実世界を反映しています。しかし、それはソフトウェア設計における重要な問題です。
私たちは、データベースからPersonオブジェクトを削除したとします。人の名前、生年月日、ジョブ記述が完全に削除されるが、アドレスにそれに対処する方法？同じ住所に住んでいる他の人があるかもしれません。あなたがアドレスを削除した場合、それらのPersonオブジェクトを削除するオブジェクトへの参照になります。あなたがアドレスを残した場合は、ごみのアドレスがデータベースに蓄積されることになります。自動ガベージコレクションのごみは対処することができますが、これは唯一の技術的な修理ではあるが、このようなデータベースシステムは、ハンドリング機構の存在が、基本的なモデリングの問題は無視したままにしても。
孤立したトランザクションを考慮した場合でも、一般的なオブジェクトモデルのネットワークもそれが困難な潜在的な影響は、修正を生成するかを決定するために作ります。システム更新の各オブジェクトへの依存性があるという理由だけで、これは非現実的です。
同じオブジェクトに複数のクライアントの同時アクセスのシステムでは、問題がより顕著です。クエリおよび更新するシステムユーザのオブジェクトの多くが、我々は彼らにも相互依存するオブジェクトを変更防ぐ必要があります。範囲エラーは重大な結果につながります。
複雑な関連を持つモデルでは、オブジェクト変更の一貫性を確保するために、それは非常に困難です。だけでなく、無関係なオブジェクトは、いくつかの固定のルールを遵守する必要がある、と密接に関連するオブジェクトの各グループは、いくつかの固定のルールに従うべきです。しかし、過度に慎重なロック機構は、システムが使用できなくなって、複数のユーザ間の相互干渉を無意味につながります。
言い換えれば、どのように我々は開始する場所の他のオブジェクトによるオブジェクトを知っていますか、そしてどこに終了するには？永続データ・ストアと任意のシステムでは、データは、トランザクションが範囲を有していなければならない変更することができるが、（固定されたルールのデータ対象を維持すること、である）データの一貫性を維持するための方法が存在しなければなりません。これは、データベースのロック機構の多様性をサポートし、検証するためにいくつかのテストを書くことができます。しかし、これらの特別なソリューションは、モデルから注意を散漫、すぐに人々は古い道路アップ「ステップによって、ステップ」に戻ります。
実際には、様々な問題にバランスのとれた解決策を見つけるために、このようなクラスの特定のインスタンスとの間の周波数の変化として根深い要因を理解するために、例えば、フィールドの深い理解を必要とします。私たちは、より密接にモデルをリンクし、より少ない固定ルールようにオブジェクト間の競合を見つける必要があります。
この問題の表面は、技術的な問題データベース情勢ですが、モデルにそのルーツを持っていますが、最終的な分析では、明確に定義されたモデルの境界が不足しているためです。モデルから派生ソリューションは、理解と通信する設計を容易にするために容易にモデル化します。モデルが変更されると、それは達成するために変更を加えるために私たちをリードします。
まず、パッケージの抽象モデルを参照する必要があります。AGGREGATEは、我々は、データ変更部として使用し、関連するオブジェクトのコレクションです。各集計は、ルート（root）とボーダー（境界）を持っています。境界は、内部AGGREGATEは何かを持って定義します。ルートは、特定のエンティティAGGREGATEは含まれています。AGGREGATEため、参照外部のオブジェクトはルートすることができ、オブジェクト間の境界の内側に相互に参照することができます。root以外のENTITYは、ローカルアイデンティティを持っていますが、ルートENTITY除く外部オブジェクトが他のオブジェクトを参照してくださいので、彼らは唯一の、唯一のAGGREGATE内区別する特定する必要があります。
自動車修理店のソフトウェアは、車のモデルを使用する場合があります。図6-2。ENTITYは、グローバルなアイデンティティを持つ車です：私たちは、世界中の他のすべての車の分野（さらにいくつかの非常によく似た車）でこの車を分離する必要があります。私たちは、区別するために、車両識別番号を使用することができ、車両識別番号は、新しい車ごとに割り当てられている固有の識別子です。私たちは、ビットで四輪をGeのタイヤの履歴を追跡するように回転することをお勧めします。私たちは、各タイヤの走行距離と摩耗を知りたいことがあります。タイヤは、ENTITYとしてマークしなければならない場合、どのタイヤを知るために。新車時のコンテキストのうち、我々はおそらく、これらのタイヤの身元を気にしないだろう。あなたが植物をリサイクルするタイヤや使用済みタイヤを交換した場合、ソフトウェアは、もはや彼らは、廃タイヤの山の一部になるだろう、それらを追跡する必要がありません。誰も彼らの回転の歴史を気にしません。さらに重要なことは、タイヤが車の中で安全であったとしても、誰もがシステムを通して特定のタイヤを照会ないだろうし、中車このタイヤを見てみましょう。人々は、データベース内の車を見つけ、その後、一時的なタイヤの状況この車を見ていきます。タイヤはこのAGGREGATEの境界内にある間そのため、車は、AGGREGATEルートENTITYです。一方、エンジンブロック上にシリアル番号が刻まれ、時には独立車が追跡されているれています。一部のアプリケーションでは、エンジンは、その集合体のルートかもしれません。
固定されたルール（不変）データが変化した場合、それはAGGREGATE部材間の内部関係に関するもので、維持されなければならない、整合性ルールを指します。そして、集計全体で任意のルールは、現在までに、すべての回で必要とされることはありません。イベント処理、バッチ、またはに依存する他の更新機構によって一定期間内に解決されます。各トランザクションが完了したときしかし、固定されたルールが適用内部AGGREGATEは、図6-3に示すように、満たされなければなりません。
さて、この概念にAGGREGATEを達成するために、我々はすべてのトランザクションのための一連のルールを適用する必要があります。
固定ルールを確認するための最終的な責任あるグローバルアイデンティティ、とENTITYのルーツ。
ENTITYのルートは、グローバル同一性を有します。唯一AGGREGATE内部だけのアイデンティティであるローカルIDとの境界内ENTITY。
AGGREGATE外部オブジェクトは、ENTITY外ルート内の任意のオブジェクトを参照することができません。参照は維持できない、ENTITY ENTITYは、渡された内部リファレンスのルートすることができますが、これらのオブジェクトは、これらの参考文献のだけ一時的に使用されています。それだけでVALUEなのでルートはもはやAGGREGATEとの任意の接続を持って、それが起こるの変更内容を気にすることなく、別のオブジェクトに渡された値オブジェクトをコピーすることはできません。
データベースを介して直接アクセスを得るために、前の規則の当然の結果、唯一のAGGREGATEルートとして。他のすべてのオブジェクトが関連をトラバースによって発見されなければなりません。
オブジェクトは、他の集計のルーツにAGGREGATE参照の内側に保持することができます。
削除操作は、AGGREGATE境界内のすべてのオブジェクトを削除する必要があります。（使用ガベージコレクションのメカニズム、原因でroot以外の他のオブジェクトの行うことは非常に簡単ですので、ルートを削除した後、他のオブジェクトが回収され、外部参照されません。）
任意のオブジェクト集合体内部境界への変更を提出する際、すべての集計を横切る固定ルールが満たされなければなりません。
私たちは、エンティティと値オブジェクトは、AGGREGATE異なるカテゴリを集め、各集計の境界を定義する必要があります。各AGGREGATEで、ルートとしてエンティティを選択し、ルートを通る境界内のすべての他のオブジェクトへのアクセスを制御します。唯一の外部オブジェクトは、ルートへの参照を保持します。内側部材への一時的な言及が出て渡されますが、1回の操作でのみ有効ことができます。ルートアクセスコントロールので、したがって、それは内部のオブジェクトを変更するために迂回することはできません。この設計はまた、任意の固定ルールを満たすために、全体としてのAGGREGATE状態が変化することを確認することができますオブジェクトを満たすすべての固定のルールを集約することを確保することができます。
あなたが自動ロック機構やその他の機能を実装することができるように、技術的な枠組みAGGREGATEが便利ですあり宣言することができます。このような技術の枠組みがなければ、チームは、使用前に合意AGGREGATEに、書き込みコードにこれらのAGGREGATEに従って自己規律に依存しなければなりません。
発注書の整合性の例
典型的な購入注文（注文、PO）ビューは、それが購買アイテム（ラインアイテム）に分解され、固定されたルールは、合計購入アイテムが全POの限界を超えることはできませんです。以下の3つの相互問題の現在の実装。
固定されたルールの実施の形態（1）。合計購入のための新しい用語が制限を超えた場合、新たな購入アイテム、総POチェックを追加する場合は、その後、POは無効としてマークされました。私たちが見るように、この保護メカニズムは十分ではありません。
（2）変更管理。POは、削除またはアーカイブされた場合、それぞれの購入アイテムは、プロセスになりますが、関係を停止すべきモデルを与えませんでした。変更部分（パート）を作製し、異なる時間に価格に影響を与える明確ではありません。
（3）データベースを共有します。複数のユーザの使用によるデータベースの問題がもたらされるだろう。
複数のユーザが入力し、それぞれ、同時にPOを更新するために、それらが互いに干渉することを防止しなければなりません。ユーザーは任意のオブジェクトの編集を開始したときに、ユーザーがトランザクションをコミットするまで、非常に単純な戦略でレッツ・スタートは、オブジェクトがロックされています。ジョージは調達品目001を編集するときにこのように、アマンダはそれにアクセスすることはできません。アマンダは、（ジョージ・編集中のPO上の他の調達品目を含む）PO上の任意の購入の他の項目を編集することができます
各ユーザーは、オブジェクトを表示および編集、データベースオブジェクトから読み出され、独自のメモリ空間でオブジェクトをインスタンス化しているが。あなたが編集を開始する場合にのみ、データベース要求がロックされます。したがって、ジョージとアマンダは、限り、彼らは同時に購入に同じ項目を編集しないと、同時に動作することができます。あなたは、同じPO上の異なるジョージとアマンダ購入アイテムの編集を開始するまで、すべてが正常です。
彼らは、トランザクション中にデータベースの変更の残りが発生した無視し、各ユーザーがロックされ、購入他の項目を変更することはできませんので、両方のユーザーの視点と視野のそれぞれのソフトウェアの観点から、その操作は、問題ではありません。2人のユーザーが変更を保存すると、データベースが固定ドメインモデルPOに格納されたルールに違反します。ビジネスの重要なルールが破壊され、誰も知りません
明らかに、単一の行をロックする十分な保護メカニズムではありません。POをロックした場合、あなたはこのような問題を防ぐことができます
アマンダは、この問題を解決するまでは、プログラムはアマンダがクォータの増加やギターを減らすことによってこの問題を解決することができ、トランザクションを保存することはできません。複数のPO間で仕事の広がりのほとんどは、これは良い解決策になる可能性がある場合、このメカニズムは、問題を防ぐことができます。さまざまなアイテムで同時に多くの人が大PO操作した場合でも、このロック機構は、非常に厄介になります。
でも、多くの小さなPO、この固定ルールを妨害する他の手段があります。さんは、「パート」を見てみましょう。アマンダため、誰かにトロンボーンは、価格トロンボーン、固定ルールを破壊しませんを変更した場合は？
また、我々は全体のPOの添加をロックしようとし、また一部は、異なるPOのジョージ、アマンダとサムの仕事はどうなるのケースをロック。
パートで競合の多くの例があったので仕事は、より多くの厄介になってきています。このような結果は、図6-10に起こるであろう：3人の個人が待つ必要があります。
今、私たちはモデルで、次のビジネス知識を追加することによって、モデルを改善するために開始することができます。
PO（1）部品番号は（高い競争を生成します）。
修飾されたPOの（2）の一部が以下の修飾を超えています。
（3）価格（価格）への変更は、必ずしも既存のPOに広がっていない、POは、どのような状態に応じて、価格を変更します。
彼らは配信され、POアーカイブされている検討する際に、第三の点は特に顕著です。彼らはもちろん、むしろ現在の価格よりも、埋めるの価格で、表示されます。
得られたPO固定ルール及び調達関連項目は、修飾された部品の価格は直ちにコンポーネント参照アイテムの調達に影響を及ぼさないであろうしながらことを保証することができ、このモデルを実装します。ルールは、より広範な関係、他の手段によって満たすことができます。ユーザーが更新または削除購入品目するかどうかを決定することができるように例えば、システムは、日々の価格の有効期限が切れて、ユーザーのためにリストされているアイテムを購入することができます。しかし、これは一定のルールのままではいけません。調達品目の一部、回避の競合への依存を減らすことによって、より良いビジネスの現実を反映します。同時に、この重要なビジネスルールの遵守を確保するために、POと購入アイテム間の関係を強化します。
AGGREGATEはPOと実際の購入項目間のそれぞれの関係に沿った事業を余儀なくされました。POと作成および削除の購入項目が自然にリンクされ、作成および削除されていることの一部は、独立しています。
範囲に分割AGGREGATEは、この範囲内で、ライフサイクルの各ステージは、ある一定の規則を満たさなければなりません。リポジトリFACTORYモードと次AGGREGATE上で動作をしている議論されるように、それらは一緒に特定のパッケージのライフサイクルの複雑さに変換される......
個人的な理解は：完全に理解していなかった、処理リソースの問題は、競争をモデル化しているようです。
工場
オブジェクトが作成されるか、作業が複雑、またはあまりにも多くの内部構造を暴露作成する場合AGGREGATEは、全体を作成する場合は、カプセル化FACTORYのために使用することができます。
オブジェクトの主な機能は、その複雑な内部側面で反射されたGeと関連しています。無関係なコンテンツの相互作用で、そのすべての意味や役割は完全にこれまでに削除されるまで、私たちは、精錬の対象とされている必要があります。そのライフサイクルのオブジェクトは、多くの責任を負担します。あなたは複雑なオブジェクトは、その作成を担当してみましょう場合は、ロールオーバーロードは、問題が発生します。
自動車のエンジンは、複雑な機械装置の部品数十から構成Geが、エンジンの職務を実行するために連携されている - シャフトを回転させます。私たちは、エンジンのセットを設計しようとすると、それはピストンとシリンダーのセットに詰めクロールさせ、スパークプラグもジャックを見つけることができますし、その中に自分のひねり自分を置くことができます。しかし、このようなAマシンの組み立ての複雑さは、私たちの共通のエンジンの信頼性や効率的なようではないかもしれません。代わりに、我々はエンジンを組み立てるために他のものを使用します。おそらく、整備士、または産業用ロボット。二つの機関は、複雑なアセンブルするよりも、それは、実際には、ロボットまたは人間であるか否か。固定部品は、仕事と完全に無関係なシャフト仕事を回転させます。私たちが運転するとき量産車がロボットや機械工を必要としないときだけは、フィッタ必要が。単一のメカニズムに組立車と同時に発生することはありませんドライバ、およびので、この2つの機能としては無価値です。同様に、複雑な複合オブジェクトの組立作業はまた、好ましくは実行される作業対象物から分離されます。
インタフェースは同じにオブジェクトのパッケージを実装する必要がありますとして（その顧客は、あなたがオブジェクトの機能を使用できるオブジェクトの作業メカニズムを知っていないこと）、FACTORYは知識が複雑なオブジェクトまたはAGGREGATEを作成するために必要なカプセル化します。これは、クライアントの目的だけでなく、作成するオブジェクトの抽象ビューを反映するためのインタフェースを提供します。
責任は、複雑なオブジェクトのインスタンスを作成することであるべきとAGGREGATEは、ドメインモデルの責任を負いませんこと自体で個別のオブジェクトに転送、それはまだ設計の分野の一部です。すべての操作インターフェースをカプセル化し、このインターフェイスは、参照、特定のクラスオブジェクトへのクライアントを必要としない、複雑なアセンブリがインスタンス化されます。作成時に凝集体は、全体としてそれを取る、それが固定されたルールを満たしていることを確認します。
FACTORY多くのデザインがあります。[ガンマらal.1995]は、ファクトリメソッド（ファクトリメソッド）、ABSTRACT FACTORY（抽象工場）、およびBUILDER（ビルダー）を含む、詳細にいくつかの特定の目的の作成モードを議論しました。この本は、最も複雑なオブジェクトの構築の問題のモードを研究しています。この本の焦点は、設計上の問題のFACTORYの徹底的な議論ではなく、重要な位置FACTORYを表示する - それは、デザインの分野の重要な要素です。FACTORYヘルプ右のトラックに沿って前方MODEL-DRIVEN DESIGNの適切な使用を確保します。
何かいい工場は、2つの基本的な要件を満たす必要があります。
（1）各原子の方法のために作成されるが、すべてのオブジェクトが作成またはAGGREGATEのルールを修正することを確実にします。FACTORYは、一貫性のある状態にあるオブジェクトを生成しました。ENTITYを生成する場合、この手段は、すべてのルールの固定全体AGGREGATE出会いを作成しますが、作成後重合にオプションの要素を追加することができます。すべてのプロパティが正しい最終状態に初期化されなければならないことをあなたが一定の値オブジェクトを作成すると、その手段。FACTORYそのインターフェイスは、オブジェクトを作成するための要求を受けたが、それは適切にオブジェクトを作成することができないなら、それは例外をスローする必要があり、または他のメカニズムは、エラーが通過値を返さないことを保証します。
（2）FACTORYは、特定のクラスを作成するのではなく、所望の種類に抽象化されるべきです。話題の紹介の[ガンマらal.1995]アドバンスFACTORYモード
個人的な理解：私は理解して、非常に複雑な場合は、オブジェクトを作成（またはパラメータの多くを組み立てるために初期化され、一定のルール）を使用すると、工場出荷時のパターンを使用することができ、技術開発者は、工場出荷時のモデルをよく知っておく必要があり、ビジネスは、工場出荷時のモデルが何であるかを知る必要はありません。
概要：、理解プログラムオブジェクトとデータベース設計のこの部分にもっと注意を払っていない、ライフサイクルモデル、デザインパターンとデータベースの設計パラダイムで良いの外観十分なはずですがあります。