7

多くのビジネス ロジックを含むプロジェクトで、DDDとDoctrine2を効果的に使用しようとしています。

システムに関連する他の概念からドメイン オブジェクトを分離する必要があることを理解しています。

しかし、私には理解しがたいことが 1 つあります。Doctrine 2 を使用した DDD のいくつかのコード例では、ドメイン エンティティの集約は Doctrine ArrayCollectionで管理されています。この種のコードを見つけました。

namespace Acme\Domain\Model\Users;

use Doctrine\Common\Collections\ArrayCollection;

class User {

     //...

    /**
    * Collection of Roles
    *
    * @var Collection of Roles
    */
    protected $roles;

    /**
    * Constructor.
    */
    public function __construct()
    {
        $this->createdAt = new \DateTime();
        $this->roles = new ArrayCollection();
    }

    public function getRoles()
    {        
        return $this->roles;
    }
//...
}

私にとって、この実装はドメイン モデルと永続化サービスDoctrine2 の間の高い結合を作成します。

一方、DDD Entity と Doctrine Entity クラスが分離されている場合、私の意見では、多くのレイヤー/クラスが存在します。

どう思いますか？これを回避/処理するより良い方法はありますか?

4

1 に答える 1

6

を使用しても心配しないでくださいArrayCollections。Doctrine/Common 名前空間にあることに注意してください。これは、Doctrine の永続レイヤーとは特に関係のない小さなユーティリティ配列ラッパーです。別の配列クラスに簡単に置き換えることができます。

マニュアルはこの問題に対処しています: https://www.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#collections。

デカップリングに関する限り、ドクトリン エンティティに限定しながら DDD モデリングを行うことは可能です。これは非常に制限的であり、一般的に推奨されません。そうです、おそらく別のレイヤーが必要になるでしょう。

PHP での純粋な DDD 実装のオーバーヘッドを正当化するのは困難です。

于 2013-08-27T20:05:12.400 に答える