多くの 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 など) を介して一般的に公開したいさまざまな属性もあります。ここでも提案を受け付けています。