12

CRUD用のDDDアプリの上にRESTレイヤーがある場合、RESTレイヤーにドメインモデル（データの観点から）を吐き出させますか（たとえばGETの場合）？

4

2 に答える 2

23

一般に、システムのパブリックインターフェイス/ APIを変更せずに、ドメインオブジェクトを変更できるようにする必要があります（たとえば、ドメインについて何か新しいことを学んだ場合）。逆の場合も同じです。パブリックインターフェイスに変更が必要な場合は、ドメインモデルを変更する必要はありません。

したがって、この観点から、パブリックインターフェイスを介してドメインオブジェクトをそのまま公開することは決してありません。代わりに、パブリックインターフェイスの一部であるデータ転送オブジェクト（DTO）を作成します。このように、私のドメインとパブリックAPIへの変更は独立して変更できます。

于 2012-06-08T08:02:39.803 に答える
2

DDDモデルを公開しないでください。SOAフロントエンドは実装の詳細をクライアントに公開してはならないため、これは絶対に正しいです。ユーザーは、実装の詳細ではなく、ビジネス機能に依存する必要があります…しかし、これは、SOAバスに統合されたいくつかの（おそらく異種の）アプリケーションの優れた設計を前提としています。

CRUDインターフェースについて言及すると、これは、アプリケーションのネットワークではなく、SOAの原則を使用してアプリケーションのレイヤーを接着する、SOAの悪用のケースである可能性があると思われるため、回答に追加したいと思います。SOAは、企業がシステムを通信するための方法であり、MVCを実装する方法ではありません。とてもシンプルですが、とても誤解されています。たとえば、フロントエンドGUIがサービスを使用してバックエンドにアクセスするという理由だけで、「SOAアプリケーション」はありません。

これがレイヤーの接着に使用されるSOAの場合である場合は、設計を修正し、そのレベルの抽象化に適した設計アーキテクチャーを使用してください。そうしないと、DDDモデルを公開せず、CRUDYを使用しないという、ここにある推奨事項を誤って解釈し、サービスインターフェイス用に別のドメインモデルを作成することになり、非常に複雑なDDDにマップする必要があります。同じものを別の名前でマッピングするには、ドーザーなどを使用する必要があります。など、肥大化した保守不可能な混乱が発生するまで続きます…</ p>

..注意してください。

-アレックス

Redzediは非常に正しいので、説明が必要です。

すべてのように、これは言うよりも行うのがかなり複雑です。複雑なドメインモデルのシリアル化は非常に難しいため、ドメインにロジックを配置しないか、貧血モデルのアンチパターン（http://martinfowler.com/bliki/AnemicDomainModel.html）を使用するか、別の貧血モデルを使用することになります。永続性、つまりDTO。

何が最悪かはわかりませんが、どちらのオプションも悪いです。モデルに含まれるロジックをモデルに配置すると、どこでも直接シリアル化できるようになります。

ドメインモデルを長年使ってきた私の経験では、一番いいのは真ん中のポイントだと思います。はい、FowlerとEvansが述べているように、ビジネスオブジェクトはロジックを実行する必要がありますが、すべてではありません（http://codebetter.com/gregyoung/2009/07/15/the-anemic-domain-model-pattern/）素敵なサービスレイヤーが最適です。

たとえば、請求書はそのアイテムについて知っている必要があり、アイテムに応じて合計を計算する手順が必要です。ただし、請求書のアイテムは請求について知る必要はありません。では、アイテムのコストが変化するとどうなりますか？循環参照として父親の請求書へのポインターを戻し、請求書の合計計算手順を呼び出す必要がありますか？

私は信じていません。これは、最初にイベントを受信して​​から手順を調整する必要があるサービスレイヤーのタスクだと思います。実装目的ですべてのビジネスオブジェクトを結合したり、ドメインモデルの目的であるビジネスインタラクションルールに違反したりする必要はありません。

-アレックス

于 2012-06-18T17:45:04.130 に答える