26

Martin Fowler は、Anemic Domain Model をアンチパターンと見なしています。

オブジェクト リレーショナル インピーダンス ミスマッチが原因で、ドメイン モデルとしての永続性モデルのローリングも大幅にオフになっているように見えます。永続性と正規化のために、クラスを非常に小さな断片に分解する傾向があります。これらのクラスの上にメソッドを平手打ちするのはばかげています。さらに、持続性はめったに変化しませんが、ビジネス ロジックはかなり変化します。

そのため、持続性モデルに基づいて構築された DomainModel が必要です (1 つの同じモデルではなく)。このドメイン モデルには、ビジネス ロジックのプロパティとメソッドが含まれます。

しかし現在、これらのドメイン モデルはまだサービスの背後にあり、それらを外部に公開するには、それらを DTO に変換する必要があります。

ここでは非常に多くのマッピングを行っています。

  1. ドメイン モデルへの永続性
  2. ドメイン モデルを DTO に変換してサービス間で受け渡すには

DTO を ViewModel にマップする必要がある場合があるため、これで終わりではありません。

クライアントはリアルタイムの検証を望んでいるため、これらすべてと検証ロジックの重複の問題は依然として解消されていません。ViewModel は検証について何も知らないため、たとえば SPA では、クライアント側で (通常は JavaScript で) 検証ロジックを再度書き直す必要があります。

また、サービスは本質的にステートレス (メッセージまたは RPC 指向) であるため、Persistence と OO との間でこれらすべてのマッピングを行い、次に Procedural に戻すと、どのような利点があるのでしょうか? ほとんどの IT 予算の実際的な観点から、コストをどのように正当化しますか?

Aggregate Roots、Domain Models などを備えた完全な DDD がいかに「クール」であるかはわかりますが、コストと開発の生産性への影響をどのように正当化できますか?

アンチパターン (またはアンチパターン) は、一般的に使用される可能性があるソーシャル オペレーション、ビジネス オペレーション、またはソフトウェア エンジニアリングで使用されるパターンですが、実際には効果がなく、非生産的です。

もしそうなら、DDD とリッチ ドメイン モデルは、「リーン」ドメイン モデルよりも上記のアンチパターンの定義に当てはまりません。申し訳ありませんが、私はロードされた単語「貧血」を軽蔑します.

ドメインモデルを「リーン」に保つことで、「抽象的な依存関係の原則」、「自分自身を繰り返さない」、およびあるデータキャリアを別のデータキャリアにマッピングするという時間のかかる退屈でエラーが発生しやすいプロセスに違反することなく、実際に共有することができます。そして、その上にある関連する単体テスト (単体テストなしでマッピングを行うことを考えていて、最善を期待している場合を除く)。

4

3 に答える 3

9

tl;dr ドメイン モデルは明確に定義されていません。おそらく、データベース中心のアプローチを念頭に置いて設計されています。

DDD の主な目的は、ビジネスの概念とプロセスをコードでモデル化することです。あなたのビジネスのコンセプトとプロセスが単なる財産の袋であるとは思えません。しかし、それらが本当に「はい」の場合、ドメイン モデルは持続性モデルと同じである可能性があるため、マッピングを行う必要はありません。

持続性モデルは、オブジェクトの状態がどのように保存されるかをモデル化します。データベースのドメインに属していない場合、ドメインと永続化モデルを同じ目的にすることはできません。DDD に関して私が目にする最大の過ちの 1 つは、ドメイン モデルを依然としてデータ駆動型であるかのように考えていることです。DDD では、具体的なデータベースはありません。リポジトリがあります。一対多、多対多などの関係はありません。テーブルも行もありません。ドメインをできるだけ正確に表現しようとするオブジェクトがあります。

簡単に言えば、ドメインはビジネス動作のモデル化に関心があり、永続性はオブジェクトの状態の保存に関心があります。ここには 2 つの異なる責任があります。

バリデーションについては、入力データ形式のバリデーションと、オブジェクト状態の変更内容に応じたその他のビジネス ルールのバリデーションの 2 種類があります。

重複については、入力形式について言及していると思いますが、@EbenRouxが言ったように、それを助けることができるメカニズムがあります。asp.net mvc では、これらの検証ルールのほとんどに js バージョンも含まれています。

サービスの秘密を教えてください。それらのインターフェースはドメインで定義できますが、それらの実装は永続レイヤーに配置できるため、ストレージを直接操作できます。アプリの残りの部分はサービスを抽象的な形式 (インターフェイス) で使用するため、DI コンテナーだけがダーティ シークレットを知っています。

DDD はクールであることではなく、ドメインに従ってアプリケーションを設計することです。データベースの UI になることだけを目的としてアプリを開発する人はほとんどいないに違いありません。大多数は、問題を解決する仮想製品を構築するために、ソフトウェアでサービスを提供することを目指しています。たまたま使用した技術的なツールではなく、解決したい問題に合わせてアプリを設計することは理にかなっています。

れんが造りの家が欲しいのに、建設業者が「申し訳ありませんが、私ののこぎりは木材でしか使えません」と言います。まあ、のこぎりを使わないで、レンガを切るのに役立つ別のツールを使ってください. ツールは、その逆ではなく、問題に合わせて調整する必要があります。

于 2013-01-17T08:38:47.110 に答える
9

多くの概念を混同しているようで、リッチドメインモデルのアプローチが直接の責任ではないことを非難しています。

  • リッチ ドメイン モデルはレイヤード アーキテクチャと直交しています。特に、リッチ ドメイン モデルを使用しても、レイヤーの数、これらのレイヤー間でどのデータ構造を交換する必要があるか、およびそれらをどのようにマッピングする必要があるかは決まりません。

  • リッチ ドメイン モデルは検証とは直交しており、バックエンドの検証に加えてクライアント側のチェックの必要性については何も述べていません。

言い換えれば、サービス内のすべてのビジネス ロジックでドメイン モデルを無力化しても、多くのボイラープレート DTO マッピング コードを記述する必要がなくなるわけではなく、クライアント側の「二重チェック」(これは一般的に受け入れられているベストプラクティスです)。

これは、本格的な多層アーキテクチャのコストと重量に関するあなたの主張が有効ではないという意味ではありません。同様の懸念について議論している Mark Seemannによる次の投稿に興味があるかもしれません。

于 2013-01-17T16:42:02.340 に答える
5

まず第一に、クライアントとサーバーで検証ロジックを複製することから本当に簡単に逃れることができるとは思いません。ただし、これは DDD に限ったことではありません。痛みを和らげるメカニズムはいくつかありますが、常に何らかの努力が必要です。

他の部分は、このマッピングビジネス全体です:)

あなたがしていることは、読み取りを実行するために効果的に使用しています。エンティティを編集するにはエンティティを読み取る必要があると考えているかもしれません。これは、エンティティ オブジェクトに対してタスク ベースの操作ではなく、エンティティ ベース (おそらくここでは DB 用語でエンティティ - レコード全体) の操作を実行している場合に当てはまります。ばかげた例として、顧客が住所を変更するためにコール センターに電話をかけることがあります。オペレーターは、顧客レコードを呼び出して住所を編集します。これはエンティティ ベースであり、2 つのアクションが同じレコードに対して実行される可能性があるため (可能性は低いですが)、同時実行に関して一般的な問題が発生します。これは、UX デザインの非常に伝統的なアプローチである「記録を編集する」です。

これを、「アドレスを変更する」という画面上のボタンと比較してください。記録上の住所を変更するだけで、これは同じことのように見えますが、実際にはまったく異なります。同じアドレスを変更する 2 つの操作の可能性は、同じレコードを変更する可能性よりもわずかです。必要に応じて、この部分で並行性チェックを実行できます。

さて、ドメインを読まないとしたら、何を読むでしょうか。データはどこから来たのでしょう。ここで CQRS (Command/Query Responsibility Segregation) の出番です。これまでは、イベント ソーシングと混同/組み合わせられてきましたが、これは必須ではありません。必要なデータを返すことに重点を置いた、アプリケーションに対する単純なクエリ サイドを作成できます。C# ではDataRow、単一のインスタンスの場合は をDataTable、複数のインスタンスの場合は を使用し、より複雑なものにはカスタム DTO を使用しました。匿名型を回避する方法があるかもしれません (これはまだ調査していません)。

したがって：

ドメイン モデル = 操作 / 計算 / 書き込み クエリ サービス = 読み取り

ドメインモデルを認識している（または認識している可能性がある）ため、Webアプリケーションなどのエンティティ/集約をロードするだけで済む状況がありますが、スマートクライアントは少しアンチパターンになります.

正当化はかなり難しいですが、それはメンテナンスに要約されます。あなたのアプローチがメンテナンスの負担を軽減していない場合は、何かが正しく適用されておらず、リファクタリングが必要な可能性があります。

DDD は技術的な実装だけではありませんが、それは適切な OO モデリングの方向性を推し進めて、長い道のりを歩んでいます。とにかく他のアイデアがソフトウェアに反映されていると思うので、とにかくソフトウェアに焦点が当てられているようです. 私たちは皆、ゴムが道路と出会う場所を見たいと思っています。

ほとんどのことと同様に、DDDは間違って実行される可能性があります:)

于 2013-01-17T04:58:32.760 に答える