ビジネス層でのモジュールの分離

Question

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

1. WebUIの
2. ビジネス
3. DataRepositories

各レイヤにのみその下の層への参照を持っています

は、我々は3層arhitectureを持っています。通信は次のように私たちは entitiesと business objects（BO）と呼ぶもので行われます。

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

<--X-->は、だから我々は、エンティティとBOとしてUserとしてたとえばUserEntityを持っているタイプX.

のオブジェクトを使用して通信を意味します。もう1つのタイプは、TicketEntityとTicketのチケットです。

現在、我々は十分に定義されており、Ticketsのような他のスライスと相互作用しないDataRepositories、ビジネスとWebUIのユーザーのためにAccountsのようなものを持つ層を貫通して、いくつかの異なる垂直スライスを持っています。

チケットには購入者がおり、チケットとユーザーの接続先は分かりません。ビジネスコンポーネントはそれらの間でやりとりする必要がありますか、データレイヤーはユーザーをチケットにマッピングする必要がありますか？

具体的には、WebUIから呼び出されたBusinessに存在するチケットを作成する方法があります。引数として、チケットの詳細と、それがタイプuserのオブジェクトかusername/idだけであるかどうかわからない "the user"をとります。 CreateTicketを呼び出す前にプレゼンテーションがユーザーを取得するユーザーオブジェクトを渡す場合。しかし、WebUIがIDを渡すと、ビジネス層はチケット（ビジネス）のユーザビジネスコンポーネントへの参照を追加する必要があるユーザオブジェクトを解決する必要があります。

Answer 1

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

私はビジネスオブジェクトを使いません。私は、不変性や他の誰かの「建築的純度」という概念の他に、あなたが挙げることができる価値を提供していないと考えています。

エンティティとリポジトリの間の矢印の向きも気に入らない。私はリポジトリにエンティティについて知ってもらいたいが、それ以外の方法は知らない。企業はなぜそれが保持されているかを知っていなければならないか、気にする必要がありますビジネスロジックとビヘイビアは変更しないでください。

私は、ビューレイヤーをサービスとやりとりさせるでしょう。これらはUIに依存しませんが、ユースケースを満たすためにすべてのビジネスロジックが含まれています。あなたがUIを捨て去った場合、そして数年に1度はあなたのサービスは、ビジネス上の問題がある限り、その場にとどまります。

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