1

私はオンライン ショップを書いており、ドメインをモデル化しているときに、さまざまなシステムから変更されたオブジェクトをさまざまな粒度でモデル化する方法についての質問が頭に浮かびました。

たとえば、いくつかの属性を持つ Product エンティティがあるとします。

  • 製品番号
  • 名前
  • 説明
  • 価格
  • 等

在庫管理システム (Web サービス経由) と e コマース製品に統合された管理 Web UI の 2 つのシステムから、新製品と製品の更新情報を受け取ります。

在庫管理から、すべての属性を含む製品の完全な更新を常に取得します (すべてが変更されていなくても)。管理 UI は、単一の属性 (crud) を更新します。

では、製品エンティティのビジネス ケース関連の変更方法をどのようにモデル化 (および名前付け) する必要があるでしょうか?

updateFromIms(price, description, name, ...) のようなものか、すべての属性のセッターを作成する必要があります (これにより、「変更不可能な」エンティティが壊れます)

4

1 に答える 1

0

疑問がある場合は、通常、サンプルの Shipping DDD アプリケーションがどのようにそれを行うかを調べます。C# のサンプル アプリケーションは、http ://code.google.com/p/ndddsample/ にあります。

したがって、あなたの場合、これはCargoエンティティの処理方法に似ており、エンティティを作成するコンストラクタがあり、BookingService によって ChangeDestination または BookNewCargo に使用される SpecifyNewRoute などのパブリック メソッドがあります。BookingService は、次の責任を持つBookingFacadeによって使用されます。

このファサードは、ドメイン レイヤー (モデル、サービス、リポジトリ) を、ユーザー インターフェイスやリモーティングなどの問題から保護します。

したがって、あなたの場合、UI と WebService は UpdateProduct という単一のファサード メソッドを呼び出すことができます (サービスからの更新と UI からの更新の間に概念的な違いはないと思うので、ChangeDestination のような別のメソッドは必要ありませんが、それはあなたの電話）。ファサード メソッドは、 ProductModel::UpdateProductを呼び出すProductService::UpdateProductメソッドを呼び出します。

あなたのアプリケーションの範囲がわからないので、これは多すぎるかもしれませんが、とにかく DDD は小さなアプリケーション向けではありません。個人的には、Eric Evans の本と NDD サンプルを参考にしていますが、一部の複雑さ (たとえば、ファサードを無視する) を取り除くことに問題はないと思います。あなたのアプリケーションをあなたよりよく知っている人はいません。

于 2012-10-21T09:08:15.337 に答える