貧血領域モデルの取り扱い

Question

DALをビジネスレイヤーから分離しようとしていたので、ActiveRecordアプローチを避け、DataMapperアプローチを採用することにしました。 言い換えれば、私のドメインオブジェクトは自分自身の永続化を気にしません。そうすることで、「貧血領域モデル」に侵入しているようです。アンチパターン。たとえば、私のプログラムのエンティティの1つは組織です。

組織は次のように表されます：

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

したがって、基本的にこの組織は「バッグ」として機能する以外の何もしません。 （Martin Fowlerが言うように）いくつかのデータについて。 PHPの世界では、それは栄光に満ちた配列にすぎません。関連付けられている動作はありません。

そしてプログラムの振る舞いは、「サービスレベル」にとどまっています。主にこれらのオブジェクトとDALの間の仲介として機能するOrganizationServiceのようなクラス。

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

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

Answer 1

まあ、最初はこのように見えますが、コードをさらにリファクタリングすると、組織クラスの動作になります...

私が今考えるかもしれない1つの例は、あなたが人々（従業員）を持っているならば、あなたは彼らを組織に関連付けることを望むかもしれません。そのため、組織クラスでその場所を見つける可能性のある AssociateEmployee（User employee）メソッドがある場合があります。

または、住所、都市、州などのパラメータを3つのステップで設定する代わりに、会社の場所を変更する場合は、 ChangeLocation（Street、City、State）メソッドを追加します。

>

ステップバイステップで、ドメインに属するように思われるBL /サービス層でコードに遭遇したら、それをドメインに移動します。 Fowlerを読んでいると、コードで見たときにすぐに入手できます。

Answer 2

今は貧血に過ぎないのでしょうか？

たとえば、一度会議/会議の登録サイトを開発していました。会議は1回だけで始まりました。

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

ドメインは時間の経過とともに変化し、モデルがリファクタリングされる可能性があることに留意することが重要だと思うので、貧弱だと思うかもしれませんが、それはほんの少し先を見越しているかもしれません設定、ルール、設定などが取得されるようになります。

Answer 3

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

これでzappanとepitkaに追加できます。

Answer 4

最初からそこにあるべきではない責任を取っているため、あなたのエンティティは貧血ではありません。エンティティの保持と取得は、リポジトリの責任です。本当にあなたの振る舞いはサービス層ではなくあなたのエンティティであるはずです。しかし、何がどこに行くかを説明することは、単純な答えをはるかに超えています。 Eric EvansによるDDDは、良い出発点です。