пожалуй, самое лаконичное описание - на википедии

Domain Driven Design

по пунктам же просили) надо объяснить что значит каждая буковка)

подожи ка, что значит каждая буква, я объяснил :)

подожи ка, что значит каждая буква, я объяснил :)

надо в гугл транслейт лезть)

http://lmgtfy.com/?q=DDD

Ну, те, кто его применял, можете своими словами?

ну на сию тему как бы умные люди целые книги пишут. Что ты хочешь услышать "своими словами"?

если совсем кратко - это правила организации ООП-кода

если написать "DDD говно", налетит обсуждальщиков) ок триггер, проверенный)

имхо это такие правила организации, при которых твой код соответствует терминам, в которых разговаривает заказчик ubiquitous language

все. как Эванс завещал, чо)

но это довольно размытое понятие

Domain Driven Design

Это когда ты проектируешь систему максимально близко отражающую бизнес-требования

А что, можно как-то по-другому?

А что, можно как-то по-другому?

вот тут я соглашусь с твоим вопросом

в любом случае система будет отражать бизнес-требования так или иначе

ну, если ты на них не забил, конечно)

Типа делаю я систему, делаю... И - бац, сделал вместо бухгалтерии игру в танчики...

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

тоже не совсем - можно сущностями выразить понятия, но этого недостаточно

А что, можно как-то по-другому?

Ну типа можно сделать слой сервисов, оперирующий репозиториями всякими и dto'шками, а можно сделать сущности, отражающие предметную область. И у тебя будет не OrderService.CancelOrder, а у самого экземпляра класса Order будет метод order.Cancel.

А есть разница?

в любом случае система будет отражать бизнес-требования так или иначе

Можно сделать по-разному. к примеру тебе нужно реализовать бизнес-требование. Пациент записывается на прием к врачу. Можно взять врача, сделатьметод записаться нга прием и передавать пациента. А можно вспомнить что происходит в поликлинике в реальности, что есть регистратура, которая записывает, и вот ты уже записываешь пациента на прием через регистратуру

За этим и нужны агрегаты.

это если очень примитивно

А есть разница?

В первом случае бизнесовая логика знает о базе (пусть и косвенно, через интерфейсы репозиториев), во втором случае - она о ней не значет ничего.

Да все проще.

У меня связующим звеном между базой и самим доменом являются обработчики команд в терминах CQRS. Ну то бишь они достают из базы агрегаты и знают как это делать. А дальше на самих агрегатах просто методы дёргаются.

Ну и после всех манипуляций, агрегаты обратно складываются в базу. А чтобы всё это дело было атомарным - оно выполняется в рамках одной транзакции.

Ну типа можно сделать слой сервисов, оперирующий репозиториями всякими и dto'шками, а можно сделать сущности, отражающие предметную область. И у тебя будет не OrderService.CancelOrder, а у самого экземпляра класса Order будет метод order.Cancel.

а еще можно застрелиться

больше сервисов-менеджеров

а почему cancel не у Order?

а еще можно застрелиться

Ну вот зачем ты трололо включил?) Я по заветам Эрика всё пишу)

На столе голубая книжечка лежит даже вот прям сейчас)

Ну вот зачем ты трололо включил?) Я по заветам Эрика всё пишу)

Эрик про другое писал

про контексты, про UL

Эрик про другое писал

Вообще оно про UL и BC

а то что книжка лежит - Эрик уже за нее извинялся что херово написал и никто ничего не понял

Но там и про техническую сторону было. Сущности там, агрегаты, методы в сущностях и т.д.

а сервисы менеджеры противоречат идее UL

а почему cancel не у Order?

всё слишком сложно, сущности - просто VO с тонной гетеров сеттеров и маппингом на базу, никакой логики. вся логика в классах типа ЧтоТоТамService. потихоньку правим, но жизнь сурова.

всё слишком сложно, сущности - просто VO с тонной гетеров сеттеров и маппингом на базу, никакой логики. вся логика в классах типа ЧтоТоТамService. потихоньку правим, но жизнь сурова.

ну тогда заветы Эванса тебе точно не нужны

всё слишком сложно, сущности - просто VO с тонной гетеров сеттеров и маппингом на базу, никакой логики. вся логика в классах типа ЧтоТоТамService. потихоньку правим, но жизнь сурова.

Ну вот эти методы должны быть у самих сущностей

раз вся логика ищ сущностей вытекла

Максимум через интерфейс может инфраструктура слегка подтекать.

Но там и про техническую сторону было. Сущности там, агрегаты, методы в сущностях и т.д.

а там было чего про доменные ивенты?

Ну типа хэшилки паролей для создания юзера.

Ну типа хэшилки паролей для создания юзера.

можешь просто выбросить из юзера хранение кредов и не надо будет инфраструктуру "протекать"

ну тогда заветы Эванса тебе точно не нужны

Ну как тебе сказать, они мне как раз и нужны, изначально всю эту грязь навёл не я, вот разгребаем сейчас. Но вообще спрашивал не я, я просто сагрился, потому что как раз в этот момент, когда сообщение увидел, на соседнем мониторе этот метод открыт был %)

Объясните, пожалуйста, простыми словами по пунктам, что есть DDD.

Проектирование программы в соответствии с реальными объектами и процессами существующими в предметной области(жизни/бизнессе). Два ключевых паттерна это общий язык и связанный контекст

Ну как тебе сказать, они мне как раз и нужны, изначально всю эту грязь навёл не я, вот разгребаем сейчас. Но вообще спрашивал не я, я просто сагрился, потому что как раз в этот момент, когда сообщение увидел, на соседнем мониторе этот метод открыт был %)

Теперь придется рефакторить и переносить метод в order

Теперь придется рефакторить и переносить метод в order

Теперь придется ждать задачу от бизнеса, которая вообще коснется этого метода. И до кучи его зарефакторить, вместе с нужными правками. Времени на "просто порефакторить" никто не даст, что логично.

В любом случае это не то чтобы сильно критично. Да, лишний слой абстракции и лишние классы, но, учитывая что это уже написано, работать особо не мешает. Это стокгольмский синдром?

Наброшу на вентилятор. По поводу отказов от сеттеров. Вот такой пример, допустим у нас есть автомобиль. Собрали его на заводе (при инициализации объекта, передали всё что нужно в конструктор) и он колесит себе просторы. Вот тут твсё хорошо. Однако, во время жизни объекта (автомобиля), его решили затонировать. Вот тут как быть? Это изменение объекта "снаружи"...

Наброшу на вентилятор. По поводу отказов от сеттеров. Вот такой пример, допустим у нас есть автомобиль. Собрали его на заводе (при инициализации объекта, передали всё что нужно в конструктор) и он колесит себе просторы. Вот тут твсё хорошо. Однако, во время жизни объекта (автомобиля), его решили затонировать. Вот тут как быть? Это изменение объекта "снаружи"...

декорация

ну и опять же ты не будешь "заменять лобовуху" во время езды, так?

во время жизни объекта, всё может быть

Decorator — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Мне кажется, что тонировка это свойство... С другой стороны - влияет на количество пропускаемого света..

Decorator — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Мне кажется, что тонировка это свойство... С другой стороны - влияет на количество пропускаемого света..

Я думаю он имел ввиду не паттерн декоратор, а то что установка тонировки - это операция *украшения* автомобиля, а не опязательно setTonirovka

Decorator — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Мне кажется, что тонировка это свойство... С другой стороны - влияет на количество пропускаемого света..

свойство чего? автомобиля? стекла?

Изменение свойств "цвет" и "прозрачность" у всех или некоторых стёкол

И/или возможно, появление градиента цветов, если совсем упороться)

Изменение свойств "цвет" и "прозрачность" у всех или некоторых стёкол

это неизменяемые свойства, на них нельзя повлиять, только наложить доп эффекты

Если нужно декомпозировать до физических свойств - да

ERROR: S client not available

Но с точки зрения пользователя же - стало темнее и изменились цвета)

Я думаю он имел ввиду не паттерн декоратор, а то что установка тонировки - это операция *украшения* автомобиля, а не опязательно setTonirovka

всё равно это изменение объекта из вне

Но с точки зрения пользователя же - стало темнее и изменились цвета)

но допустим если ты купил стекло с заводской тонировкой светлее ты его уже не сделаешь, только темнее

С точки зрения пользователя - он купил стекло не с теми свойствами)

Все зависит от того, насколько глубоко нужно моделировать

Кто и как будет взаимодействовать с объектом

всё равно это изменение объекта из вне

объекьы всегда будут изменяться во время взаимодейсвтия. Суть в том чтоб инкапсулирвоать реализацию. То есть один объект должен посылать другому сообщение "затонируйся" а не "установиСвойствоТонировкаВОпределенныйЦвет"

объекьы всегда будут изменяться во время взаимодейсвтия. Суть в том чтоб инкапсулирвоать реализацию. То есть один объект должен посылать другому сообщение "затонируйся" а не "установиСвойствоТонировкаВОпределенныйЦвет"

В чёрном ящике "стекло" сообщение Затонируйся вполне может быть реализовано сменой свойств, что сразу повлияет на поведение

объекьы всегда будут изменяться во время взаимодейсвтия. Суть в том чтоб инкапсулирвоать реализацию. То есть один объект должен посылать другому сообщение "затонируйся" а не "установиСвойствоТонировкаВОпределенныйЦвет"

объект1 дёргает методы объекта2 в любом случае же. Только не объект2.Стёкла.Цвет=СероБуроМалиновый, а объект2.Затонируйся(ПараметрыТонировки)

объекьы всегда будут изменяться во время взаимодейсвтия. Суть в том чтоб инкапсулирвоать реализацию. То есть один объект должен посылать другому сообщение "затонируйся" а не "установиСвойствоТонировкаВОпределенныйЦвет"

зачем объекту изменяться? это будет уже не тот объект )))

зачем объекту изменяться? это будет уже не тот объект )))

ФП какое-то)

Тот

зачем объекту изменяться? это будет уже не тот объект )))

если это сущность то можно и поменяться

а если VO то воссаздать свою копию с измененными свойствами

Меняется состояние, интерфейс тот же

а если VO то воссаздать свою копию с измененными свойствами

ну, это будет уже другой объект

новый

А поведение зависит от состояния, что не так?

ну, это будет уже другой объект

А VO и должны быть иммутабельными.

объекьы всегда будут изменяться во время взаимодейсвтия. Суть в том чтоб инкапсулирвоать реализацию. То есть один объект должен посылать другому сообщение "затонируйся" а не "установиСвойствоТонировкаВОпределенныйЦвет"

а если у тебя будет 2 объекта которые можно затонировать, «тонировкаАвэрИнтерфейс» ?, они оба будут уметь принимать сообщение «затонируйся»?)

а если у тебя будет 2 объекта которые можно затонировать, «тонировкаАвэрИнтерфейс» ?, они оба будут уметь принимать сообщение «затонируйся»?)

да а что н так?

кто нибудь может объяснить схему HTTP =(a)> Command => Command Bus => Command Handler => Event => Event Dispatcher => Event Subscriber => (maybe repeat to (a)

??

о, моя тема) что интересует?

во время жизни объекта, всё может быть

если все может быть - то ты либо пишешь на смолтаке каком, либо что-то делаешь не так

о, моя тема) что интересует?

Да вот пытаюсь въехать во всю эту движуху. Вроде разобрался что пиздато когда контроллер из запроса создает Команду(dto по сути) котоаря описывает какие то действия, далее команда передается в comandBus где обрабатывается разными хендлерами. Если я не прав , то поправьте.

кто нибудь может объяснить схему HTTP =(a)> Command => Command Bus => Command Handler => Event => Event Dispatcher => Event Subscriber => (maybe repeat to (a)

ну вот смотри, приходит у тебя http запрос, ты из него выдираешь данные и пихаешь в команду (это что-то типа данных для юзкейса) и кидаешь в шину, которая находит нужную реализацию этого юзкейса и чето машнит. То, с чем ты чего-то машниш кидает ивент о том что что-то случилось. Ивенты после коммита транзакции собираются и кидаются на обработку. А там дальше что хочешь делай. Хочешь - проекции данных, хочешь - email-ы отправляй

Да вот пытаюсь въехать во всю эту движуху. Вроде разобрался что пиздато когда контроллер из запроса создает Команду(dto по сути) котоаря описывает какие то действия, далее команда передается в comandBus где обрабатывается разными хендлерами. Если я не прав , то поправьте.

хендлер команды уже как один, слушать ивенты могут много слушателей

а) ты ответил на мой вопрсо из соседнего чата

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

чем листенеры отличаются от хендлеров??