2

私たちの新しいプロジェクトは始まったばかりで、そのアーキテクチャに関連する問題があります。

3 層のアーキテクチャがあります。

  1. WebUI
  2. 仕事
  3. データリポジトリ

各レイヤーは、その下のレイヤーのみを参照します。通信は、次のようentitiesに and business objects(BO) と呼ばれるもので行われます。

DataRepositories <--entities--> Business <--BO--> WebUI

<--X-->タイプ X のオブジェクトを使用した通信を意味します。

したがって、たとえばUserEntityエンティティUserとして、BOとして持っています。もう 1 つのタイプはTicketEntity、 とを持つチケットTicketです。

現在、DataRepositories、Business、および WebUI のユーザー向けのような層を通る明確な垂直スライスがいくつかありAccountsます。これらは明確に定義されており、他のスライスとは相互作用しませんTickets。

ここでの問題は、チケットにはユーザーである購入者がいて、アーキテクチャのどこでチケットとユーザーを接続すべきかわからないことです。ビジネス コンポーネントがそれらの間で対話する必要がありますか、それともデータ レイヤーがユーザーをチケットにマップする必要がありますか?

より具体的には、ビジネスに常駐し、WebUI から呼び出されるチケットを作成するメソッドがあります。これは、チケットの詳細と「ユーザー」を引数として取ります。これは、タイプ user のオブジェクトである必要があるのか​​、単にユーザー名/ID である必要があるのか​​はまだわかりません。CreateTicket を呼び出す前に、プレゼンテーションがユーザーを取得する必要があるというユーザー オブジェクトを渡す場合。ただし、WebUI が ID を渡す場合、ビジネス レイヤーはユーザー オブジェクトを解決する必要があります。これには、チケット (ビジネス) のユーザー ビジネス コンポーネントへの参照を追加する必要があります。

4

1 に答える 1

2

個人的には、このような並列階層は嫌いです。エンティティと呼んでいるものを作成しました。これには、何らかの動作が関連付けられている必要があります。さらに、不変で動作のないビジネス オブジェクトの並列階層が必要です。

私はビジネスオブジェクトを省きます。それらは、不変性と他の誰かの「アーキテクチャの純粋さ」の概念以外に、あなたが引用できる価値を提供していないと思います。

また、エンティティとリポジトリの間の矢印の方向も好きではありません。リポジトリにエンティティについて知ってもらいますが、その逆はありません。永続化されているかどうかをエンティティが認識または気にする必要があるのはなぜですか? ビジネス ロジックと動作は変更しないでください。

ビューレイヤーがサービスと対話するようにします。これらは UI に依存しませんが、ユース ケースを満たすためのすべてのビジネス ロジックが含まれています。UI を破棄した場合 (数年ごとに破棄する場合もあります)、ビジネス上の問題が解消される限り、サービスはそのまま残ります。

データ層は、それ自体の参照整合性を担当する必要があります。チケットがそのユーザーを見つけるために JOIN する必要がある場合は、それをデータ層に含める必要があります。永続層がユーザーに対してクエリを実行すると、そのユーザーに属するチケットも取得され、オブジェクトで 1 対 5 の関係が返されます。ユーザーは、チケット インスタンスのリストまたはセットを持ちます。これはすべてサービス層で行う必要があります。このサービスは、永続性、ビジネス オブジェクト、およびユース ケースを満たすために必要なその他のサービスを調整します。

于 2011-06-26T17:59:02.980 に答える