0

注 - すべての引用はDDD: Tackling Complexity in the Heart of Software からのものです。

最初の引用 ( 222 ページ ):

ドメイン オブジェクトとしてのプロセス

前もって、手順をモデルの重要な側面にしたくないことに同意しましょう。オブジェクトは手順をカプセル化するためのものであり、代わりにオブジェクトの目標や意図について考えさせてくれます。

私が話しているのは、ドメインに存在するプロセスであり、モデルで表現する必要があります。これらが出現すると、扱いにくいオブジェクト デザインになる傾向があります。

この章の最初の例では、貨物を発送する配送システムについて説明しました。このルーティング プロセスは、ビジネス上の意味を持つものでした。サービスは、非常に複雑なアルゴリズムをカプセル化しながら、そのようなプロセスを明示的に表現する 1 つの方法です。

2 番目の引用 (104,106 ページ):

時々、それはただのことではありません。場合によっては、最も明確で実用的な設計には、概念的にどのオブジェクトにも属さない操作が含まれます。問題を強制するのではなく、問題空間の自然な輪郭に従い、サービスを明示的にモデルに含めることができます。

ドメイン内の重要なプロセスまたは変換がエンティティまたは値オブジェクトの自然な責任ではない場合、サービスとして宣言されたスタンドアロン インターフェイスとして操作をモデルに追加します。モデルの言語に関してインターフェイスを定義し、操作名がユビキタス言語の一部であることを確認します。

最初の引用で著者が「プロセス」という用語を使用して、2番目の引用と同じタイプの動作（これもService内にカプセル化する必要があります）を説明しているのか、それとも「プロセス」という用語が使用されているのかわかりません彼が104、106ページで説明しているものとはかなり異なる種類の行動を説明していますか?

ありがとうございました

4

2 に答える 2

2

概念はかなり近いですが、私には、最初の引用は、ソフトウェアなしで存在するであろう大規模な実世界のドメインプロセス（たとえば、「貨物ルーティングプロセス」）に関するもののように見えます。

2つ目はあまり明確ではありませんが、モデル化されたバージョンのドメインで行われるより小さな操作/プロセス/変換について説明していると思います。

前者は分析の初期段階からすぐに「サービス」としてクリックする必要がありますが、後者はより微妙で、通常のエンティティの動作と区別するのに時間がかかる可能性があります。最初はエンティティに含めることもできますが、そうではないことに気づきます。モデルを改良するときに、その量に合わせます。

于 2013-01-29T09:28:34.677 に答える
1

pで考えます。222 彼は特定の種類のプロセスについて話している. pのように。102引用、それらはサービスとして実装できます。ただし、一部のプロセスは実際のドメイン プロセスを参照しており、モデル内の明示的な表現からメリットを得ることができます。これはすぐにはわからないかもしれませんが、サービスを超えたより洗練されたオブジェクト モデルが必要になる可能性があります。

于 2013-01-29T05:05:21.377 に答える