1

MVC アプリケーションを構築しています。「M」層は、サービス層、ドメイン モデル層、およびマッパー層で構成されています。

私のドメイン モデルのロジックは非常に複雑です。たとえば、組織には多くの従業員がいます。組織/従業員の給与レベルなどの側面を変更したい場合は、組織オブジェクト、ユーザー オブジェクト、およびこの 2 つを接続する従業員オブジェクトを参照する必要があります。通常、私はこれらの責任を構成オブジェクト (この場合は組織) に課してきましたが、それはうまく機能しています。

私が苦労している 1 つの問題は、新しいエンティティの作成に関連しています。具体的には、新しいエンティティの作成を管理する条件/ルールがある場合、これらはサービス層またはドメイン層に存在する必要がありますか?

最も確実なオプションは、ロジックをドメイン モデル レイヤーに配置することだと私には思えますが、そうすると、私のドメイン オブジェクトは「純粋ではない」ように見えます。たとえば、作成者に関係なく、Employee オブジェクトは Employee オブジェクトです。しかし、Employee エンティティを作成するルールが作成者に依存する場合、作成者を Employee オブジェクトに挿入する必要があります。(従業員オブジェクトを作成するための私のルールは、それを作成した組織管理者か、古いユーザーかによって異なります)。

作成ルールをサービス層に配置する方が自然に思えますが、これには 2 つの問題があります。まず、ドメイン モデルへのすべてのアクセスがそのサービス レイヤー経由であることを完全に確認する必要があります。(これは大したことではありません。) さらに重要なことは、私のビジネス ロジックが 2 つのレイヤーにまたがって広がっていることです。

私は、事前にバリケートするのをやめて、ロジックをサービス レイヤーに配置する必要があると考えています。どう思いますか？

参考までに、私はPHP、Zend FrameworkをjQuery/javascriptフロントエンドで使用しています。

4

2 に答える 2

-1

ビジネス ルールはドメイン層の一部であるべきだと思います。

ZeissS が示唆するように、ドメイン層にはファクトリが適しているようです。または、ファクトリの代わりに、Employee クラス自体に検証メソッドを含めることができます。Employee を作成するドメイン オブジェクトはその検証を実行し、エラーが発生した場合は例外をスローします。 このようにして、誰が検証を行うのか、何が行われるのかを分離します。

説明するために、ファクトリを Employee クラスに含めています。

Organization.createEmployee( employee input fields...) {
Employee employee = new Employee();
employee.setfirstName(firstName);
employee.setLastName(firstName);

...
then 
employee.validatePosition();
employee.validatePayRate(); //throw exception if error

同様に、ユーザーが従業員を作成している場合、同じことを行いますが、検証はユーザーに関係します。

このパターンがあなたのドメインに適合するかどうかはわかりません。また、例として示したものは非常に単純化されていますが、原則は依然として当てはまります。お役に立てれば！

于 2013-07-09T18:54:50.987 に答える