Меню
Что нового?

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

  • Автор темы Автор темы Vano
  • Дата начала Дата начала
 
Вурдалак написал(а):
UserProfile лучше сделать value object'ом (embeddable).
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
http://www.amazon.com/gp/product/03..._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 - накидайте пожалуйста ссылок.
 
stalxed написал(а):
Но если честно - этого ничтожно мало, я до сих пор не представляю концепцию DDD на уровне целого проекта.
Нажмите для раскрытия...
Судя по содержанию книг, у меня был чистый DDD в одном из проектов.
Точнее не на проекте, а на группе взаимосвязанных проектов.
 
Кстати, даже структура проекта весьма интересна какая должна быть.
Т.е. сердце DDD - изоляция domain layer от остальных слоёв.

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

Но голова закружится наверное от такой иерархии.
Т.е. по сути есть например контекст Billing.
Будет Application/BillingBundle, Domain/BillingBundle, Infrastructure/BillingBundle.
Реальная жесть....
 
stalxed написал(а):
А на каком фреймворке был проект? И какая структура файлов была, мини схему бы :)
Нажмите для раскрытия...
Каждый сабдомен в отдельном проекте (symfony). Каждый сабсабдомен в отдельном бандле :)
Естественно не без грязи, иногда бандлы зависели друг от друга.
 
Последнее редактирование:
stalxed написал(а):
https://gist.github.com/satooshi/6396551
Нажмите для раскрытия...
Это какая-то хрень. Очень symfony specific (бандлы, DI-конфиги в папках Domain), валидаторы в Domain (признак anemic model), схемы ORM в папке Domain, в Application микс из application layer и presentation и т.д.

stalxed написал(а):
Т.е. по сути есть например контекст Billing.
Будет Application/BillingBundle, Domain/BillingBundle, Infrastructure/BillingBundle.
Нажмите для раскрытия...
Bundles — это нечто фреймворко-специфичное. Это разумно, например, для infrastructure и presentation, потому что они как раз зависят от фреймворка, конкретных деталей.
 
Последнее редактирование:
Вурдалак, для меня bundle - это структура, которой symfony предоставляет DI контейнер.
Всё остальное в bundle не имеет значения(является придатком и легко можно выпилить).
И вот в домене DI контейнер я бы применил.
Сервисы domain уровня собрать через него.
Это предоставит дополнительные плюсы: стратегии вычислений удобно регистрировать как DI теги, и прочие сложные domain структуры собирать через DI контейнер.
 
Чейта вы похоже в текстурах застряли. DDD - это проектирование сверху вниз, от предметной области к деталям реализации, а не наоборот. Фреймворки, структура файлов, анемичная или активная модель это вообще пятое дело. Потребители доменной логики взаимодействуют только со сводными корнями. Они не взаимодействую с моделью напрямую.
 
stalxed написал(а):
И вот в домене DI контейнер я бы применил.
Сервисы domain уровня собрать через него.
Это предоставит дополнительные плюсы: стратегии вычислений удобно регистрировать как DI теги, и прочие сложные domain структуры собирать через DI контейнер.
Нажмите для раскрытия...
При чем тут сам DI, я говорю DI-конфиги. Symfony DIC — это деталь реализации (есть ещё php-di, Pimple, etc.), никакого упоминания в domain layer об этом быть не должно.
 
whirlwind написал(а):
Чейта вы похоже в текстурах застряли. DDD - это проектирование сверху вниз, от предметной области к деталям реализации, а не наоборот. Фреймворки, структура файлов, анемичная или активная модель это вообще пятое дело. Потребители доменной логики взаимодействуют только со сводными корнями. Они не взаимодействую с моделью напрямую.
Нажмите для раскрытия...
Чучка не читатель? :)
 
Вурдалак написал(а):
При чем тут сам DI, я говорю DI-конфиги. Symfony DIC — это деталь реализации, никакого упоминания в domain layer об этом быть не должно.
Нажмите для раскрытия...
Но слой верхнего уровня может вызывать слой нижнего уровня.
Поэтому зависимость домена от инфраструктуры не фатальна.

Книга Эрика Эванса если под рукой, там рисунок 4.1
 
stalxed написал(а):
Но слой верхнего уровня может вызывать слой нижнего уровня.
Поэтому зависимость домена от инфраструктуры не фатальна

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

DI-конфиги — это однозначно инфраструктура. Мне неинтересно знать детали реализации, которые они как раз раскрывают, что типа UserRepository — это MysqlUserRepository, параметры соединения с базой и т.д.
 
Да я читаю и не могу вкурить чего вы из пустого в порожнее переливаете четвертую страницу. Берем сервис, распространяем на всю модель и сужаем до контекста задачи, профит. Или вы обсуждаете очередной способ запудрить себе мозги? Ну, не буду мешать :)
 
Вурдалак написал(а):
Это тот рисунок, где написано «этот рисунок показывает проблемы неизолированности предметной области»?
Нажмите для раскрытия...
dpTIqH4.png

Взято из книги "Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем" Эрика Эванса.
 
Вурдалак написал(а):
stalxed, ты текст только под рисунком читаешь?
Нажмите для раскрытия...
Я хочу сказать, что предметный уровень находится выше, чем инфраструктурный, а значит может его вызывать.
Как иначе в этом примере Account может добавить объект в UnitOfWork?
Поэтому что плохого может быть, если в Domain уровне использовать конфиги DI для объявления сервисов domain уровня?
А без bundle это никак не сделать, т.е. domain layer тоже должен быть bundlом.
 
whirlwind написал(а):
Да я читаю и не могу вкурить чего вы из пустого в порожнее переливаете четвертую страницу.
Нажмите для раскрытия...
Ты зашёл, увидел DDD и решил, что тема про DDD? Наивный чукотский юноша. Это phpclub, тут такого не бывает, тут оффтопик.

whirlwind написал(а):
Берем сервис, распространяем на всю модель и сужаем до контекста задачи, профит.
Нажмите для раскрытия...
Слющай, дарагой, биреш и пишешь код, прафит.
 
Войдите или зарегистрируйтесь для ответа.
Сверху