2

多くの CRUD 機能を含むアプリケーションに DDD を実装し、ある種の Web API と組み合わせると、プラットフォームが提供するツールでは比較的単純にすることができたことが、より困難になるという状況に陥ります。例えば：

User オブジェクトがあり、貧血ドメイン モデルを作成しないように懸命に努力しているため、より表現力豊かな操作がモデル化されているとします。

class User {
    public void terminateAccount(TeminationReason reason);
    public void reactivateAccount();
}

上記のクラスは、アカウントを終了済みとしてマークし、理由をすぐに設定できるため、便利です。setEnabled(false) および setTerminationReason(..) より明らかに改善されています。

問題は、そのユーザーに対して GET/PUT できる JAX-RS Web サービスのようなものがあるとしましょう。フレームワーク (JAX-RS、JAXB) は、DTO オブジェクトを簡単にシリアライズおよびデシリアライズします。さて、以前はできたはずの場所：

entity.setEnabled(dto.isEnabled);
entity.setTerminationReason(dto.getTerminationReason);

代わりに:

if (entity.isEnabled() && !dto.isEnabled()) {
    entity.terminateAccount(dto.getTerminationReason);
} else if (!entity.isEnabled && dto.isEnabled) {
    entity.reactivateAccount();
}

ここでの大きな違いは、ドメイン オブジェクトのビジネス指向のインターフェイスと、RESTful API を介した CRUD スタイルのアクセス パターンです。DDD と REST はどちらもそれ自体がベスト プラクティスであるため、上記のコードの負担や反復性などを軽減するために、ここで学んだ教訓は何ですか?

PS - バックグラウンドで ORM フレームワークを使用する場合、遅延読み込みを制限できないため、実際にエンティティを XML/JSON にシリアル化することが問題になるため、DTO を使用しています。また、ドメイン モデルに属さない、RESTful API (参照 URL など) を介して一般的に公開したいさまざまな属性もあります。ここでも提案を受け付けています。

4

1 に答える 1

4

Userここでの問題は、単一のDTOを使用してすべてのAPIのエンティティを表現しようとしていることだと思います。代わりに、必要なデータのみを含む、操作ごとに個別のDTOがある場合、コードははるかに単純になります。

たとえば、TerminateAccountAPIには終了理由のみのDTOがあり、コードは次のようになります。

user.terminateAccount(dto.terminationReason);
于 2012-07-23T03:43:23.887 に答える