symfony — чистый доменный дизайн в PHP-проекте
В «PHP World» есть странное чувство об уровне инфраструктуры в любом приложении DDD (пример), что я мог найти.
Я вижу много примеров, когда разработчики используют Doctrine2 на уровне инфраструктуры используйте объекты домена (из уровня домена) в качестве Doctrine2 модели, размещая на ней комментарии к документам, или упоминайте их в конфигурации (xml, yml).
Например, Пример Большой Синей Книги, Здесь расположены доменные объекты: https://github.com/codeliner/php-ddd-cargo-sample/tree/master/CargoBackend/src/Model, и, как вы можете видеть, он тесно связан с Доктриной (смотрите аннотации). Они ?
Я чувствую, что это неправильно.
Что я понял о DDD, это:
Репозиторий должен выполнить запрос к постоянному слою и передать результат фабрике для создания экземпляра. Aggregate Root сущность (модель предметной области) правильно. Это означает, что только Фабрика знает, как конкретный Aggregate Root может быть создан, более того, существует так называемый цикл сущностей. Это означает, что не каждый раз, когда сущность Домена должна создаваться (гидрироваться) через __construct,
Если у меня правильное чувство, то где хороший пример правильного использования? Doctrine2 в DDD-подобном приложении?
Решение
Я не совсем понимаю ваш вопрос, но постараюсь ответить на него.
ORM на уровне домена
ORM is best way to easily map your domain objects to your database layer.Тот факт, что он использует вашу модель предметной области, не связывает ее с вашими совокупностями и интересами. People are scared, что им нужно иметь чистый доменный слой, поэтому людям нравится отображать свой доменный слой с помощью xml, yml. я бы сказал feel free to map it by annotations, если вы уверены, что you're not going to change orm framework in the future, Это поможет разработчикам, которые приходят на ваше место, легко изменить отображение. А в PHP вы можете быть уверены, что эта доктрина будет № 1 долгое время, так что не стесняйтесь ее использовать.
Но будьте осторожны с использованием ActiveRecord, потому что он действительно связывает вас с фреймворком. Если вы не хотите использовать ORM, вам нужно использовать чистое отображение SQL. Если у вас сложный домен, удачи с этим 🙂
Не бойся связи
Если у вас есть чувство, что PHP lack features и они должны быть встроены в нативный php, не стесняйтесь использовать их непосредственно в вашей модели. Например, я использую Doctrine ArrayCollection как часть моей модели, потому что, если бы я использовал Java, например, у меня были бы типы Collections непосредственно на языке. Это просто PHP is retarded with some features и нам нужно немного помочь;)
То же самое относится и к фреймворкам, которые вы, вероятно, в любом случае внедрили бы на уровне домена, например, Broadway для поиска событий.
Не борись со своими рамками
Иногда вы обнаружите, что фреймворк, который вы используете, например, ORM, не позволяет вам делать вещи, как вы бы этого хотели. Вы выбрали рамки, и если вы не хотите ее менять, не боритесь с ней. Вы должны принять это со всеми его преимуществами и недостатками.
Читать Красную книгу Вона Вернона
Я вижу, что вы не очень хорошо понимаете строительные блоки.
Фабрика отвечает за строительство объектов в начале их жизненного цикла.
Репозиторий отвечает за сохранение состояния и извлечение его из базы данных.
Сначала нужно начать с Красной книги, в ней много примеров. Я бы назвал это гораздо более дружелюбным для начинающих DDD, чем Синяя книга.
Другие решения
Других решений пока нет …