Тонкий контроллер, всё в моделях

[Вурдалак]

Я хочу сказать, что предметный уровень находится выше, чем инфраструктурный, а значит может его вызывать.
Как иначе в этом примере Account может добавить объект в UnitOfWork?
Поэтому что плохого может быть, если в Domain уровне использовать конфиги DI для объявления сервисов domain уровня?
А без bundle это никак не сделать, т.е. domain layer тоже должен быть bundlом.

У Domain есть контракт AccountRepository, он больше ничего не знает. Это обеспечивается инфраструктурой и только она знает про реализацию:
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Contract/TripRepository.php
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/InfrastructureBundle/Resources/config/services.xml#L10

Т.е. я не понимаю почему ты не можешь просто поместить папку в другое место. Просто папку в другое место. Оно будет работать. Поверь мне.

 

[stalxed]

Вурдалак, это применение паттерна Separated Interface. Ну да, убираем зависимость от инфраструктуры и конкретной реализации.
С UnitOfWork можно тоже самое сделать. Времени теряется дай боже...

Но складывать зависимости между сервисами домена не получится без DI контейнера.

Пример из текущего проекта:
Domain Layer:
- Сервис подсчета лимитов заказа(зависит от правил)
- Множество правил(1 правило - 1 класс) подсчета лимитов, некоторые из них тоже зависят от чего-то...
- SomeOrderSpecification - зависит от сервиса подсчета лимитов, так как необходимо получить лимиты заказа.

Как это всё "склеивать" без DI контейнера?

 

[Вурдалак]

Как это всё "склеивать" без DI контейнера?

Блин, ты реально дурачок? Я где-то говорил, что я против контейнера? Просто DI-конфиги должны быть в другой папочке, окай? Ты будешь, выражаясь красивыми словами, дистиллировать модель и тут же в этой же папке хранить настройки соединения с базой для MySqlAccountRepository? лол.

Вурдалак, это применение паттерна Separated Interface.

Ты пытаешься любое понятие смаппить на паттерн из PoEAA? Чисто интуитивно разве неясно зачем это нужно? Если ты напрямую зависишь от MySQL, то ты не понял DDD вообще, ты напрямую зависишь от базы, от структуры, ты не можешь разрабатывать, пока не сделаешь таблицу, не сможешь написать интеграционный тест без гребаного MySQL, заменив на InMemoryAccountRepository и т.д. смешиваешь кишки реализации и модель. Сначала модель. Потом SQL и прочая хрень. Или No SQL. Но сначала модель.

С UnitOfWork можно тоже самое сделать. Времени теряется дай боже...

Это уже чисто инфраструктура, там вообще насрать.

 

[stalxed]

Просто DI-конфиги должны быть в другой папочке, окай?

Конфиги DI можно использовать и как правила доменной модели.
Например есть OneOrderSpecificatiom, TwoOrderSpecificatiom, ThreeOrderSpecificatiom - из них можно получать новые спецификации прямо в конфиге DI(при помощи OrSpecification, AndSpecification, NotSpecification).
Конфиг DI можно легко использовать как средство настройки модели, и в этой настройке будут использоваться правила относящиеся к домейн области.
Очень часто бывает из одного класса при разном конструирование можно создать разные сервисы, в зависимости от переданных значений.
Поэтому DI конфиги очень даже относятся к domain.

 

[Вурдалак]

Например есть OneOrderSpecificatiom, TwoOrderSpecificatiom, ThreeOrderSpecificatiom - из них можно получать новые спецификации прямо в конфиге DI(при помощи OrSpecification, AndSpecification, NotSpecification).

У этой новой спецификации должно быть какое-то имя, это должно иметь какой-то смысл в контексте домена. Нужно создать класс-спецификацию, где явно написать этот код. DI-конфиги ты притягиваешь за уши. Я не понимаю этих попыток притянуть в модель то, без чего легко можно обойтись.

 

[Redjik]

ну чо замолчали то?
продолжайте набрасывать на вентилятор =))))

хороший тред получился, Вурдалак, может займешься и соберешь все в одну статью хорошую это?

 

[grigori]

боюсь, ты не по адресу, на одном сарказме статью не написать

 

[Вурдалак]

Я не вижу тут никаких откровений и тред очень бессистемный, каждый говорит о своём. Например, Грише везде мерещится AR, хлебом не корми, дай что-нибудь сказать на эту тему.

 

[grigori]

одна из самых эффектных техник флейма - опровержение дефиниций, которых нет
ответить на это нечего, а чтобы понять - надо вникать

ладно, я уже троллю

 

[Вурдалак]

одна из самых эффектных техник флейма - опровержение дефиниций, которых нет
ответить на это нечего, а чтобы понять - надо вникать

А что я опровергаю? Я просто констатирую факт: тред раздут, в основном из-за некомпетентности, ты — яркий тому пример. Я правда не стесняюсь в выражениях, потому что ты иногда лезешь в тему с умным видом, не понимая суть разговора, что только создаёт никому не нужный шум. Причём ты скорее удавишься, чем признаешь неправоту.

 

[Redjik]

Откровений да, нету. Как бе DDD уже изобретено.
Вопрос в другом, я хочу накидать статейку, как отрефакторить поэтапно приложение,
MVC wtih SL -> MVC with DIC -> Framework Decoupling -> Action Model Domain Response -> Hexagonial
И прийти к выводу, что вот у нас и получилось из всего этот DDD приложение ....
И типа - не надо говнарить, пишите сразу по DDD =)

Что думаешь?

ЗЫ. Типа как у Лео, только с другой стороны. Он кстати на слайдах очень неплохо про DDD рассказывает.

 

[grigori]

я бы спросил иначе: а какое из чужих утверждений ты _не_ опровергаешь?
даже конструктивную и очень хорошую по сути идею Redjik-а пытаешься девальвировать

 

[Вурдалак]

Redjik, Yii головного мозга вылечил? Подскажи клинику некоторым товарищам.

Что думаешь?

Отношусь к этому, как к антирелигиозной пропаганде: одобряю, но тратить собственное время на это у меня нет сил.

 

[WMix]

а мне понравился тред и ссылками и доводами, я не понял о чем вы там спорили, просто кучка отобранных ссылок, сидишь значит, а тут инфа падает... (правда я медленный еще не все прочел)