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

[Вурдалак]

UserProfile лучше сделать value object'ом (embeddable).

P.S. Кстати, по DDD, архитектуре есть чо?

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
http://www.amazon.com/gp/product/0321834577/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687542&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0321125215&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=045ZG0AHN98AFR6XMPRX

http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202/ref=sr_1_1?s=books&ie=UTF8&qid=1425294374&sr=1-1&keywords=ddd c# — не читал, но вроде советуют.

 

[stalxed]

UserProfile лучше сделать value object'ом (embeddable).
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
http://www.amazon.com/gp/product/0321834577/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687542&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0321125215&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=045ZG0AHN98AFR6XMPRX

По поводу этих книг.
Первая книга(Big Blue Book) есть на русском, и хорошо переведена.
Вторую(The Red Book) читал пару глав на английском, переговаривал с русским издательством, в течение 2-3 месяцев будет.

Периодически читаю группу: https://groups.google.com/forum/#!forum/dddinphp

Но если честно - этого ничтожно мало, я до сих пор не представляю концепцию DDD на уровне целого проекта.
И реальных подобных проектов не видел.

Кто знает open source projects/bundles/modules/etc на DDD - накидайте пожалуйста ссылок.

 

[Absinthe]

Но если честно - этого ничтожно мало, я до сих пор не представляю концепцию DDD на уровне целого проекта.

Судя по содержанию книг, у меня был чистый DDD в одном из проектов.
Точнее не на проекте, а на группе взаимосвязанных проектов.

 

[stalxed]

Кстати, даже структура проекта весьма интересна какая должна быть.
Т.е. сердце DDD - изоляция domain layer от остальных слоёв.

Например:
https://gist.github.com/satooshi/6396551

Но голова закружится наверное от такой иерархии.
Т.е. по сути есть например контекст Billing.
Будет Application/BillingBundle, Domain/BillingBundle, Infrastructure/BillingBundle.
Реальная жесть....

 

[stalxed]

Судя по содержанию книг, у меня был чистый DDD в одном из проектов.
Точнее не на проекте, а на группе взаимосвязанных проектов.

Прочитайте книги и обновите этот пост.

 

[Absinthe]

Прочитайте книги и обновите этот пост.

Ок, через 5 минут

 

[stalxed]

Ок, через 5 минут

А на каком фреймворке был проект? И какая структура файлов была, мини схему бы

 

[Absinthe]

А на каком фреймворке был проект? И какая структура файлов была, мини схему бы

Каждый сабдомен в отдельном проекте (symfony). Каждый сабсабдомен в отдельном бандле
Естественно не без грязи, иногда бандлы зависели друг от друга.

 

[Вурдалак]

https://gist.github.com/satooshi/6396551

Это какая-то хрень. Очень symfony specific (бандлы, DI-конфиги в папках Domain), валидаторы в Domain (признак anemic model), схемы ORM в папке Domain, в Application микс из application layer и presentation и т.д.

Т.е. по сути есть например контекст Billing.
Будет Application/BillingBundle, Domain/BillingBundle, Infrastructure/BillingBundle.

Bundles — это нечто фреймворко-специфичное. Это разумно, например, для infrastructure и presentation, потому что они как раз зависят от фреймворка, конкретных деталей.

 

[stalxed]

Вурдалак, для меня bundle - это структура, которой symfony предоставляет DI контейнер.
Всё остальное в bundle не имеет значения(является придатком и легко можно выпилить).
И вот в домене DI контейнер я бы применил.
Сервисы domain уровня собрать через него.
Это предоставит дополнительные плюсы: стратегии вычислений удобно регистрировать как DI теги, и прочие сложные domain структуры собирать через DI контейнер.

 

[whirlwind]

Чейта вы похоже в текстурах застряли. DDD - это проектирование сверху вниз, от предметной области к деталям реализации, а не наоборот. Фреймворки, структура файлов, анемичная или активная модель это вообще пятое дело. Потребители доменной логики взаимодействуют только со сводными корнями. Они не взаимодействую с моделью напрямую.

 

[Вурдалак]

И вот в домене DI контейнер я бы применил.
Сервисы domain уровня собрать через него.
Это предоставит дополнительные плюсы: стратегии вычислений удобно регистрировать как DI теги, и прочие сложные domain структуры собирать через DI контейнер.

При чем тут сам DI, я говорю DI-конфиги. Symfony DIC — это деталь реализации (есть ещё php-di, Pimple, etc.), никакого упоминания в domain layer об этом быть не должно.

 

[Вурдалак]

Чейта вы похоже в текстурах застряли. DDD - это проектирование сверху вниз, от предметной области к деталям реализации, а не наоборот. Фреймворки, структура файлов, анемичная или активная модель это вообще пятое дело. Потребители доменной логики взаимодействуют только со сводными корнями. Они не взаимодействую с моделью напрямую.

Чучка не читатель?

 

[stalxed]

При чем тут сам DI, я говорю DI-конфиги. Symfony DIC — это деталь реализации, никакого упоминания в domain layer об этом быть не должно.

Но слой верхнего уровня может вызывать слой нижнего уровня.
Поэтому зависимость домена от инфраструктуры не фатальна.

Книга Эрика Эванса если под рукой, там рисунок 4.1

 

[Вурдалак]

Но слой верхнего уровня может вызывать слой нижнего уровня.
Поэтому зависимость домена от инфраструктуры не фатальна

Книга Эрика Эванса если под рукой, там рисунок 4.1

Это тот рисунок, где написано «этот рисунок показывает проблемы неизолированности предметной области»?

DI-конфиги — это однозначно инфраструктура. Мне неинтересно знать детали реализации, которые они как раз раскрывают, что типа UserRepository — это MysqlUserRepository, параметры соединения с базой и т.д.

 

[whirlwind]

Да я читаю и не могу вкурить чего вы из пустого в порожнее переливаете четвертую страницу. Берем сервис, распространяем на всю модель и сужаем до контекста задачи, профит. Или вы обсуждаете очередной способ запудрить себе мозги? Ну, не буду мешать

 

[stalxed]

Это тот рисунок, где написано «этот рисунок показывает проблемы неизолированности предметной области»?

Взято из книги "Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем" Эрика Эванса.

 

[Вурдалак]

stalxed, ты текст только под рисунком читаешь?

 

[stalxed]

stalxed, ты текст только под рисунком читаешь?

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

 

[Вурдалак]

Да я читаю и не могу вкурить чего вы из пустого в порожнее переливаете четвертую страницу.

Ты зашёл, увидел DDD и решил, что тема про DDD? Наивный чукотский юноша. Это phpclub, тут такого не бывает, тут оффтопик.

Берем сервис, распространяем на всю модель и сужаем до контекста задачи, профит.

Слющай, дарагой, биреш и пишешь код, прафит.