貧血ドメインモデルを扱う

Question

DALとビジネスレイヤーを分離しようとしていましたが、ActiveRecordのアプローチをやめ、DataMapperのアプローチをとることにしました。 つまり、私のドメインオブジェクトは自分自身を永続化することはありません。そうすることで、私は "貧血ドメインモデル"のアンチパターンを侵略しているようです。たとえば、私のプログラムのエンティティの1つは組織です。

組織は、このようなものとして表されます。

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
} 

だから、基本的には、この組織は、いくつかのデータのために（Martin Fowler氏が言うように）「バッグ」として行為以外の何もしません。 PHPの世界では、それは栄光の配列以上のものではありません。それに関連する動作はゼロです。

プログラム内での動作は、ほとんどがこれらのオブジェクトとDALの間の仲介役をするOrganizationServiceのような "サービスレベル"クラスに固執しています。

PHPの潜在的なスケーリングの問題以外（私はこれらのオブジェクトに自分のデータを「詰め込む」ことを主張する理由があります）、このアプローチは完全にオフですか？

このような状況でドメインモデルをどのように処理しますか？ おそらく、組織は私のドメインの一部ではないでしょうか？

Answer 1

さて、私は今考えるかもしれません

一例...、それは最初にこのように思えるが、あなたはもっと自分のコードをリファクタリングよとき、あなたはあなたの組織のクラスのいくつかの行動に取得します人（従業員）がいる場合は、それらを組織に関連付けることができます。そのため、あなたの組織クラスでその場所を見つけるかもしれない方法AssociateEmployee(User employee)があるかもしれません。

それとも、代わりに住所、市、三の段階での状態のようなパラメータを設定するので、あなたがChangeLocation(Street, City, State)メソッドを追加するかもしれませんが、会社の場所を変更する場合があります。..

あなたはいくつかのコードが発生したときだけ、一歩一歩を行きますあなたはドメインに属しているはずのBL /サービス層をドメインに移動します。あなたがFowlerを読んだら、あなたのコードでそれを見るとすぐにそれを得るでしょう。

Answer 2

今はちょうど貧血かもしれませんか？

たとえば、私は会議/会議登録サイトを開発していました。それは1回の会議から始まりました。

会議のクラスとインスタンスは1つしかありませんでしたが、翌年には会議が開催され、拡張され、新しいプロパティが追加されました（2つのバックツーバック会議を開催するため）。まだ十分に開発されていませんでした。その後、複数の会議を含む会議グループを追加しました。

ドメインが時間とともに変化し、モデルがリファクタリングされる可能性があることを覚えておくことが重要だと思うので、貧血だと思うかもしれませんが、クラスはいくつかの設定、ルール、設定などを取得し始めます）。

Answer 3

あなたの存在は、そこには存在してはならない可能性があるため、貧血ではありません。エンティティの永続化とフェッチは、リポジトリに対応しています。本当にあなたの行動は、サービス層にないエンティティにあるべきです。しかし、どこに行くのかを説明することは、単純な答えを超えたものです。エリックエバンスによるDDDは良い出発点です。

Answer 4

ビジネスルールがあまりない場合や、ドメインが複雑でない場合は、そのDDDがオーバーヘッドになる可能性があるとも考えられます。 DDDは大規模で複雑なドメインにとって優れたソリューションですが、単純にデータを出してデータを出しているのであれば、オーバーヘッドや複雑さがあります。 DDDは設計が難しく、本質的に複雑さを増すので、それを正当化するためには、問題領域の複雑さがそれを上回るはずです。

zappanとepitkaに追加するのはこれだけです。