0

ビジネス ロジック層には、ビジネス ロジックを含むビジネス オブジェクトが含まれます。それらのいくつかは永続的であり、それらはエンティティです。エンティティとそのロジックがモデルを構成します。それらの一部はステートレスであり、エンティティの責任に適合しない追加のロジックが含まれています。これらのオブジェクトはサービスです (モデルの一部でもありますか?)。

次に、マネージャー、ファクトリー、ビルダーなどのヘルパー/ユーティリティ クラスがいくつかあります。今のところ、この分解は正しいですか?

次に、エンティティまたはサービスではなく、状態を含むことができるオブジェクトがあります。独自のスレッドを持つアクティブなオブジェクト。長生きできる。それらのオブジェクトは何ですか? ビジネスオブジェクトだけですか、それともビジネスコンポーネントですか?

私のプロジェクトには Device クラスがあります。DBに格納されるので、最初はEntityオブジェクトのように扱いました。実際のデバイスから定期的にデータを取得し、そのデータで複雑なロジックを実行する独自のスレッドが含まれています。したがって、それはアクティブで長寿命のオブジェクトです。重い/複雑でアクティブで長寿命のオブジェクトであるため、エンティティになれないことに気付きました（または???）。だから私はそれを別々のクラスに分割しました：

  • 現在エンティティである DeviceDescriptor と
  • 複雑なビジネス ロジックを含む DeviceAccess (または Device ) は、存続期間が長く、アクティブです。また、DeviceDescriptor オブジェクトに基づいて初期化されます。

この DeviceAccess オブジェクトはどのような種類のビジネス オブジェクトですか?

このような構造のプロジェクトがある場合、Device/DeviceAccess オブジェクトは名前空間階層のどこに配置する必要がありますか?

  • ProjectName.Core – コア オブジェクト、ビジネス オブジェクト
  • ProjectName.Core.Entities – 持続性ビジネス オブジェクト
  • ProjectName.Core.Services – サービス インターフェイス
  • ProjectName.Core.Services.Default – サービスの実際の実装
  • ProjectName.Core.Repositories – (DAL レイヤー) リポジトリ インターフェイス
  • ProjectName.Core.Repositories.SqlServer – リポジトリの実際の実装

まず、このオブジェクトを Core 名前空間に配置する必要があると考えました。しかし、別のコンポーネント/モジュールまたは機能のように扱い、 Core 名前空間の外に ProjectName.Devices (他のヘルパー オブジェクト、リポジトリ、およびエンティティ - DeviceDescriptor と共に) を配置する方がよいのではないかと考えました。どう思いますか？

名前空間の構成が正しいかどうかも教えてください。DDDによるガイドではありませんでした。これは、DDD からいくつかの概念を借用した 3 層アーキテクチャです。(リポジトリ、集約ルート、サービス、モデル)。

アドバイスをいただければ幸いです。

4

1 に答える 1

0

ビジネス ロジック層には、ビジネス ロジックを含むビジネス オブジェクトが含まれます。それらのいくつかは永続的であり、それらはエンティティです。エンティティとそのロジックがモデルを構成します。それらの一部はステートレスであり、エンティティの責任に適合しない追加のロジックが含まれています。これらのオブジェクトはサービスです (モデルの一部でもありますか?)。

ドメインには、集約、エンティティ、値オブジェクト、イベント、サービスなどが含まれます。エンティティとは、ライフサイクルを持ち、ID によって識別される概念を意味します。

次に、マネージャー、ファクトリー、ビルダーなどのヘルパー/ユーティリティ クラスがいくつかあります。今のところ、この分解は正しいですか?

マネージャとは何ですか? それらはドメイン内の概念を表していますか? ファクトリは、集約ルートまたはエンティティに実装するのが最適です。考えてみてくださいvar post = forum.PostBy(user);。ビルダーは、複雑なオブジェクトを構築し、言語をサポートするのに役立ちます。例えば; carBuilder.PaintedIn(red).Spinning(bigRims)....

次に、エンティティまたはサービスではなく、状態を含むことができるオブジェクトがあります。独自のスレッドを持つアクティブなオブジェクト。長生きできる。それらのオブジェクトは何ですか? ビジネスオブジェクトだけですか、それともビジネスコンポーネントですか?

あなたが探しているのは、Saga または Process Manager でしょうか?

私のプロジェクトには Device クラスがあります。DBに格納されるので、最初はEntityオブジェクトのように扱いました。実際のデバイスから定期的にデータを取得し、そのデータで複雑なロジックを実行する独自のスレッドが含まれています。したがって、それはアクティブで長寿命のオブジェクトです。重い/複雑でアクティブで長寿命のオブジェクトであるため、エンティティになれないことに気付きました（または???）。だから私はそれを別々のクラスに分けました..

それは間違いなくエンティティである可能性があり、おそらく集約ルートです。複数の値オブジェクトのエンティティを構成していますか? 値オブジェクトは、ロジックをカプセル化する優れた方法です。

このような構造のプロジェクトがある場合、Device/DeviceAccess オブジェクトは名前空間階層のどこに配置する必要がありますか?

ProjectName.Core – コア オブジェクト、ビジネス オブジェクト ProjectName.Core.Entities – 永続化ビジネス オブジェクト ProjectName.Core.Services – サービス インターフェイス ProjectName.Core.Services.Default – サービスの実際の実装 ProjectName.Core.Repositories – (DAL レイヤー) リポジトリ インターフェイスProjectName.Core.Repositories.SqlServer – リポジトリの実際の実装

技術的なパターンではなく、機能に基づいた名前空間を検討しましたか? 機能に基づいた名前空間コマンドの例を次に示します。

于 2013-06-27T07:49:20.573 に答える