Поясните за DDD

сынок, это фантастика

Это который Data driven? Никакая не фантастика

мимо

Что несут в себе или должны нести Domain services ?

Что несут в себе или должны нести Domain services ?

Бизнес-логика

та, которая не лезет в domain model

та, которая не лезет в domain model

по какой причине она не может залезть в model ?

Эт какая то херовая картинка

не совсем правильно выразился скорее, которая делегирует задачи самим моделям и координирует их но тут все довольно зыбко

не совсем правильно выразился скорее, которая делегирует задачи самим моделям и координирует их но тут все довольно зыбко

Трындец. А оно в итоге полезное то хоть что-то делает?

Эт какая то херовая картинка

Можно конкретнее?

Трындец. А оно в итоге полезное то хоть что-то делает?

ну зависит от того, как спроектируешь в этом весь прикол ddd - сложно говорить о конкретной реализации, не зная нюансов домена

Можно конкретнее?

Вот оригинал

И на нём апликейшн под инфраструктурой

А то что выше эту я вообще видел только в докладе про ddd в yii)

Трындец. А оно в итоге полезное то хоть что-то делает?

Надо создать юзера. Чтобы его создать - надо знать имя и пароль. Но пароль я же не буду в открытом виде в сущность писать. Надо же захэшировать и посолить. То есть надо задействовать какой-то сервис, отвечающий за хэширование. Но ты же не будешь его в конструктор модели передавать. Поэтому делаешь отдельный сервис, который знает про то, что перед созданием юзера, надо захэшировать его пароль. Ну то бишь он занимается хешированием (вызов отдельной инфраструктурной штуки) и конструированием сущности. Хотя возможно пример говно))

Перевод оригинальной статьи тут: https://habrahabr.ru/post/233747/

А то что выше эту я вообще видел только в докладе про ddd в yii)

Это оттуда и взято. Она скорее про слои в приложении, а твоя более абстрактная - для понимания, что такое теория DDD в принципе.

профит есть вообще от DDD? или все равно со временем размазывается вся бизнес логика?

профит есть вообще от DDD? или все равно со временем размазывается вся бизнес логика?

Есть

профит есть вообще от DDD? или все равно со временем размазывается вся бизнес логика?

если не умеешь - то нет :D

ddd это не [только] про код ведь

если не умеешь - то нет :D

ну тут понятно )

профит есть вообще от DDD? или все равно со временем размазывается вся бизнес логика?

Есть. Не размазывается. Но если с DDD не работал и начинаешь делать Ъ, то количество бизнес-правил в модели становится таким, что офигеваешь)

Надо создать юзера. Чтобы его создать - надо знать имя и пароль. Но пароль я же не буду в открытом виде в сущность писать. Надо же захэшировать и посолить. То есть надо задействовать какой-то сервис, отвечающий за хэширование. Но ты же не будешь его в конструктор модели передавать. Поэтому делаешь отдельный сервис, который знает про то, что перед созданием юзера, надо захэшировать его пароль. Ну то бишь он занимается хешированием (вызов отдельной инфраструктурной штуки) и конструированием сущности. Хотя возможно пример говно))

Чото сложно

А если у меня просто функции?

А если у меня просто функции?

мы толератно относимся к функциональным, не переживай

это не про ddd

А если у меня просто функции?

Ну живут они тогда в домене

Что значит в домене?

а если без троллинга - расскажи, как это организовано у вас мне как человеку с ООП головного мозга интересно

Ну живут они тогда в домене

"просто функции" лежат "просто в модулях". А далье уже какие-то из модулей представляют domain layer

как написать большое приложение (абстрактную црмку) в функциональном подходе

у тебя ж не только функции в модуле, но и типы с которыми эти функции работают

как написать большое приложение (абстрактную црмку) в функциональном подходе

яж не настоящий фпшник, у меня жаваскрипт

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

ну ок)

у тебя ж не только функции в модуле, но и типы с которыми эти функции работают

Ну у меня С#. Функции являются методами агрегатов и сами по себе нигде не болтаются.

Ну у меня С#. Функции являются методами агрегатов и сами по себе нигде не болтаются.

опять мешанина терминов

человек спросил как быть если у него модули это не классы а... модули)

а ты начал про c# и что "ложи в домен"

как написать большое приложение (абстрактную црмку) в функциональном подходе

Монадок навернуть

а ты начал про c# и что "ложи в домен"

my fault(

ай, короч пока возникают вопросы "куда код ложить" рано в DDD

Монадок навернуть

у меня ООП головного мозга, я про монады читал, но ничего не запомнил)

потому что в DDD этих вопросов в разы больше

у меня ООП головного мозга, я про монады читал, но ничего не запомнил)

из моего примитивного понимания - монада это про чейнинг. Пример монады - промисы например. Вся суть в чейнинге.

вот реально, вернон хоть и читается непросто, но глаза открывает

из моего примитивного понимания - монада это про чейнинг. Пример монады - промисы например. Вся суть в чейнинге.

ну, я могу в php возвращать $this на объектах)

и буду чейнить по самые помидоры

но это такое, в порядке бреда в это нужно серьезно вникнуть

ну это чуть более конкретно... посмотри как реализуется Maybe монада)

это не про ddd

А про что же?)

луковая архитектура - это не ддд

А про что же?)

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

про то что хорошая система не должна ограничивать бизнес

ты чуть напутал) ддд - про то, что ты написал

а картинка - не про ддд, а просто про архитектуру

Разве ddd в слоистом представлении кода не будет выглядеть похожим образом?

может выглядеть, может не выглядеть

Разве ddd в слоистом представлении кода не будет выглядеть похожим образом?

да но ddd не требует "слоистого" представления кода

оно требует разделения ответственности

ERROR: S client not available

да но ddd не требует "слоистого" представления кода

Ну разумеется ddd это теория, а не конкретное представление

ты можешь этого добиться и не только за счет слоев. Более того, хоть и подразумевается что модель "должна быть чистой" в реальности абсолютно чистой ты ее не можешь сделать

Ну разумеется ddd это теория, а не конкретное представление

ну твоя картинка это тоже теория и причем в неумелых руках ты получишь лазанью

чистой - без примесей инфраструктурных штук?

чистой - без примесей инфраструктурных штук?

да

ну не только инфраструктурной, те же пересечения контекстов, что там у Эванса в главах про дисциляцию

со слоями оно чуть проще воспринимается в общем и целом нужно меньше вкуривать в бизнес

типа тут у нас контроллер, тут репо и так далее

для слоев лучше покурить гексагоналку

гекса тоже не везде нужна

там их в простом варианте 2

она ведь вроде под soa больше, нет?

"приложение" и "наружка"

она ведь вроде под soa больше, нет?

почему? пофигу

оно про грамотное использование инверсии зависимостей, про снижение связанности

ну в принципе да тут название подвело, "порты и адаптеры" звучит здесь лучше

ну в принципе да тут название подвело, "порты и адаптеры" звучит здесь лучше

ну порты и адаптеры это последняя версия названия)

1 штука "портов и адаптеров" тоже к нему относится)

гексагоналкой ее называл Кокберн потому что на бумажке когда схемки рисовал ему нравилось все гексагонами изображать)

я помню, я читал ту статейку

красиво рисовалось, ну и назвал)

ну и норм)

профит есть вообще от DDD? или все равно со временем размазывается вся бизнес логика?

если у тебя нет заинтересованных лиц, если никто не заинтересован в развитии бизнеса, ну и в целом если проект развития не подразумевает (single event app какой) то DDD профита не дает. Профит от DDD особенно хорошо проявляется на больших проектах, когда нет одного человека который знает все бизнес процессы необходимые.

так сказать что бы устранить стоимость перевода требований с языка бизнеса на технический язык

если у тебя нет заинтересованных лиц, если никто не заинтересован в развитии бизнеса, ну и в целом если проект развития не подразумевает (single event app какой) то DDD профита не дает. Профит от DDD особенно хорошо проявляется на больших проектах, когда нет одного человека который знает все бизнес процессы необходимые.

получается нужно не только ООП но и хорошие навыки БА, чтобы успешно DDD применять?

именно

(ну и "хорошие навыки БА" это просто здравый смысл и умение в приоритизацию)

по поводу "когда брать ДДД" - Вернон, 29 страница

там табличка об этом)

как называется книга Вернона? )

Мне уже @fes0r советовал Эванса