Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>1)Не указаны задачи, решаемые создаваемой программой
I>Вообще то ответ на это есть в книге в той самой первой главе.
Я не нашел, приведешь цитату?

G>>2)Не указано почему сначала создавалась именно структура, а потом функции
I>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
Нет, именно сначала структура, а потом функции. Причем самое интересное что очень много времени отведено именно поиску подходящих названий, а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.

I>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей. А вот структура предметной области как раз подлежит "раскапыванию", именно об этом и вся первая глава книги эванса. Вот только никто не гарантирует что раскопанная структура будет адекватна для решаемых задач.


G>>3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"
I>Не ясно, что ты имел ввиду.
Ну например имея нарисованную ER диаграмму предметной области не обязательно её 1-в-1 переводить в классы. Зачастую это излишне.

Здравствуйте, gandjustas, Вы писали:

G>>>1)Не указаны задачи, решаемые создаваемой программой
I>>Вообще то ответ на это есть в книге в той самой первой главе.
G>Я не нашел, приведешь цитату?

Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.

Далее он рассказывает про стуктуру модели на примере функции "прозванивание".

Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."

I>>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
G>Нет, именно сначала структура, а потом функции.

Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.

>Причем самое интересное что очень много времени отведено именно поиску подходящих названий,

Да, он и пишет — "ввели в обиход язык основаный на модели"

>а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.

Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи. Потом адаптировали под это дело модель

Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения

I>>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
G>Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей.

Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.

Валяй, пиши что ты из этого понял и как это приспособить к дизайну.

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

Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.

G>>>3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"
I>>Не ясно, что ты имел ввиду.
G>Ну например имея нарисованную ER диаграмму предметной области не обязательно её 1-в-1 переводить в классы. Зачастую это излишне.

Необязательно, да. А иногда только так и можно. Он не пояснил свой выбор. Я правда, дальше первой главы не прочел, может дальше что будет, только на этой недели книга пришла.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>>>1)Не указаны задачи, решаемые создаваемой программой
I>>>Вообще то ответ на это есть в книге в той самой первой главе.
G>>Я не нашел, приведешь цитату?

I>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
Уж очень профессиональный подход...

I>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

I>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
Непонятно зачем это.

I>>>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
G>>Нет, именно сначала структура, а потом функции.
I>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
Структура без функций никому не нужна. Структура является средством реализации функций.
А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.

>>Причем самое интересное что очень много времени отведено именно поиску подходящих названий,
I>Да, он и пишет — "ввели в обиход язык основаный на модели"
Это далеко не самое главное.

>>а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.
I>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

I>Потом адаптировали под это дело модель
То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

I>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
G>>Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей.

I>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
И?

I>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
Где требования\пожелания пользователей?

Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.

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

I>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?
А если вдруг не подходит, то переделывать структуру?

Отличная статья на эту тему из соседнего вопроса.

ЗЫ. Кстати эванс описывает в книге задачe моделирования (ну по крайней мере они свел задачу к моделированию), что хорошо решается средствами ООП. Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.

Здравствуйте, gandjustas, Вы писали:

I>>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
G>Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
G>Уж очень профессиональный подход...

А где взять программиста, который специалист по проектированию печетных плат ?

I>>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
G>Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

Именно так — сначала разбирается с тем, что же ему надо делать. В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.

I>>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
G>Непонятно зачем это.

Это уточняется что же такое прозвон цепи.

I>>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
G>Структура без функций никому не нужна. Структура является средством реализации функций.

Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.

G>А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.

Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.

I>>Да, он и пишет — "ввели в обиход язык основаный на модели"
G>Это далеко не самое главное.

Он с тобой не согласен.

I>>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
G>А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.

I>>Потом адаптировали под это дело модель
G>То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели. К

I>>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
G>И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
G>И?

Тебе ничего из этого непонятно, правда ?

I>>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
G>Где требования\пожелания пользователей?

У меня этого почти никогда не было, за 10 лет

G>Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.

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

I>>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
G>То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?

Конечно, кастомер должен хотя бы высказать, чего же он хочет. Наприер — рассчет прозвона.

G>А если вдруг не подходит, то переделывать структуру?

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

G>Отличная статья на эту тему из соседнего вопроса.

Это не интересно. Фигуры всякие это для школьников.

G>Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.

А он и не утверждает, что все задачи должны решаться через DDD.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
G>>Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
G>>Уж очень профессиональный подход...

I>А где взять программиста, который специалист по проектированию печетных плат ?
Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

I>>>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
G>>Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

I>Именно так — сначала разбирается с тем, что же ему надо делать.
Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

I>В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.
Да это и не является необходимым. Главное чтобы на человеческом языке объяснили каких результатов ждут и какие входные данные есть.

I>>>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
G>>Непонятно зачем это.
I>Это уточняется что же такое прозвон цепи.
Логично. Зачем уточняется, как этот прозвон будет выглядеть в программе? Будет ли он там вообще? Может он и не нужен инженерам.

I>>>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
G>>Структура без функций никому не нужна. Структура является средством реализации функций.

I>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
Конечно, потому что любая система ценна функциями, а не структурой.
Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции. Получилось — ура, не получилось — видимо мало используется исконно DDDшных паттернов: DTO, CQRS итп.

G>>А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.
I>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
Прям по тексту: сначала структуры, потом функции.

I>>>Да, он и пишет — "ввели в обиход язык основаный на модели"
G>>Это далеко не самое главное.
I>Он с тобой не согласен.
Только он свое мнение никак не обосновывает.

I>>>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
G>>А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

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

I>>>Потом адаптировали под это дело модель
G>>То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

I>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
Непонятные для мня слова какие-то.

I>>>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
G>>И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
G>>И?

I>Тебе ничего из этого непонятно, правда ?
Ага.

I>>>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
G>>Где требования\пожелания пользователей?
I>У меня этого почти никогда не было, за 10 лет
А как ты можешь узнать что ты вообще делаешь что-то полезное?
Или ты исключительно распилом бюджетов занимаешься?

G>>Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.
I>Конечно. В этом вся фишка, когда нужно лезь куда то, кроме как "заказчик-заказ-позиция" или "фигуры", надо начинать с самых азов, т.е. с базовых понятий.
Зачем? Можешь обосновать такую точку зрения? Считаешь продуктивным изучать предметную область в отрыве от решаемых задач или наоборот считаешь полезным обучение кастомеров программированию?

I>Только потому, что кастомер часто вообще не имеет представления о программировании.
И что?

I>>>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
G>>То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?
I>Конечно, кастомер должен хотя бы высказать, чего же он хочет. Наприер — рассчет прозвона.
Вот дальше его желания можно декомпозировать, по простой схеме. Любая программа состоит из трех частей: входные данные, алгоритм, выходные данные.
Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.

Далее функции можно группировать. Например по общности входных данных, по общности выходных данных, по общности выполняемых действий.


G>>А если вдруг не подходит, то переделывать структуру?

I>Более того — переделывать постоянно, в т.ч. под конкретную задачу, как прозвон. Он ведь именно это и демонстрирует. А потом пишет, что все то же было проделано для всех функций.
То есть первоначальные изыскания по поводу структур нужны только чтобы восполнить пробел в знаниях проектировщика? Причем тут DDD тогда?

G>>Отличная статья на эту тему из соседнего вопроса.
I>Это не интересно. Фигуры всякие это для школьников.
Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.

G>>Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.
I>А он и не утверждает, что все задачи должны решаться через DDD.
Ну а какие должны?

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

Здравствуйте, gandjustas, Вы писали:

I>>А где взять программиста, который специалист по проектированию печетных плат ?
G>Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?

I>>Именно так — сначала разбирается с тем, что же ему надо делать.
G>Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.

I>>В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.
G>Да это и не является необходимым. Главное чтобы на человеческом языке объяснили каких результатов ждут и какие входные данные есть.

Он из них и вытягивал — см. диалог.

G>>>Непонятно зачем это.
I>>Это уточняется что же такое прозвон цепи.
G>Логично. Зачем уточняется, как этот прозвон будет выглядеть в программе? Будет ли он там вообще? Может он и не нужен инженерам.

Нужен. см. диалог. Специалист 2(по книге) говорит о том, для чего это надо.

I>>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
G>Конечно, потому что любая система ценна функциями, а не структурой.

Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.

G>Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции.

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

По твоему это натягивать функции на модель ?

I>>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
G>Прям по тексту: сначала структуры, потом функции.

Чушь. Диалог прочти то, там где речь про прозванивание.

I>>Он с тобой не согласен.
G>Только он свое мнение никак не обосновывает.

В первой главе — возможно.

I>>Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.
G>У разных типов программ даже юзкейсы разные, ты на одну модель не натянешь любой набор функций, так чтобы не пришлось менять эту модель.

Функции и не натягиваются. Модель под функции подбирается. Он и пишет, цитирую(лень набирать, кое что я опускаю) :

"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."

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

I>>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
G>Непонятные для мня слова какие-то.

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

I>>Тебе ничего из этого непонятно, правда ?
G>Ага.

А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.

I>>У меня этого почти никогда не было, за 10 лет
G>А как ты можешь узнать что ты вообще делаешь что-то полезное?

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

I>>Конечно. В этом вся фишка, когда нужно лезь куда то, кроме как "заказчик-заказ-позиция" или "фигуры", надо начинать с самых азов, т.е. с базовых понятий.
G>Зачем? Можешь обосновать такую точку зрения? Считаешь продуктивным изучать предметную область в отрыве от решаемых задач или наоборот считаешь полезным обучение кастомеров программированию?

Предметная область изучается в контексте решаемых задач.

I>>Только потому, что кастомер часто вообще не имеет представления о программировании.
G>И что?

Он не может сформулировать задание толком.

G>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.

Эванс в книге именно это и демонстрирует.

I>>Более того — переделывать постоянно, в т.ч. под конкретную задачу, как прозвон. Он ведь именно это и демонстрирует. А потом пишет, что все то же было проделано для всех функций.
G>То есть первоначальные изыскания по поводу структур нужны только чтобы восполнить пробел в знаниях проектировщика? Причем тут DDD тогда?

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

I>>Это не интересно. Фигуры всякие это для школьников.
G>Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.

Разве чьи то фигуры и датчики Буча говорят что либо про книгу Эванса ?

I>>А он и не утверждает, что все задачи должны решаться через DDD.
G>Ну а какие должны?

Я еще не прочел всю книгу

G>А применимость для сложных задач не удалось пока никому доказать. Особенно не для задач моделирования.

Что значит доказать применимость ?

В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.

Просто модели бывают разными, вот и всё.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>А где взять программиста, который специалист по проектированию печетных плат ?
G>>Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

I>В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?
"Бухучет" это уже готовая модель вообще любого учета. Очень желательно не изобретать свои модели, а использовать то что проверено временем.

I>>>Именно так — сначала разбирается с тем, что же ему надо делать.
G>>Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

I>Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.
Так пусть заказчик оплатит обучение на ускоренных курсах инженеров печатных плат. Вообще заказчик обычно платит за решение своих проблем, а не решение проблем разработчиков ПО.

I>>>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
G>>Конечно, потому что любая система ценна функциями, а не структурой.
I>Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.
Такс, уже пошли по кругу... Я вот утверждаю что не надо "вникать", чаще всего достаточно того что сообщает потенциальный пользователь. А если "бизнес" заказчика сложен, то появляется дополнительный слой аналитиков, которые могут рассказать это все гораздо лучше.

G>>Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции.

I>"По мере того как инженеры описывали мне новые нужные им функции, я заставлял их проходить пошаговые сценарии взаимодействия объектов. Если объекты модель не справлялись с задачей прохождения алгоритма, мы вносили изменения. Мы улучшали модель и в месте с ней эволюционировал код"

I>По твоему это натягивать функции на модель ?
Именно, зачем было заранее создавать модель, тем более в коде. Любой написанный код стоит денег и ограничивает "пространство маневра". Лучше код не писать, или писать такой чтобы его без проблем можно было выкинуть. Всеобъемлющая Domain Model как раз полная противоположность.

I>>>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
G>>Прям по тексту: сначала структуры, потом функции.
I>Чушь. Диалог прочти то, там где речь про прозванивание.
А до прозванивания что? Там же тоже диалоги есть.

I>>>Он с тобой не согласен.
G>>Только он свое мнение никак не обосновывает.
I>В первой главе — возможно.
А в последующих тем более. Там он технические аспекты рассматривает в основном.

I>>>Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.
G>>У разных типов программ даже юзкейсы разные, ты на одну модель не натянешь любой набор функций, так чтобы не пришлось менять эту модель.
I>Функции и не натягиваются. Модель под функции подбирается. Он и пишет, цитирую(лень набирать, кое что я опускаю) :
I>"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."
Да я не против, пусть модель создают. Но эванс пытается модель создавать опираясь не на функции, а на "предметную область" (1), реализовывать модель в коде в виде классов с "поведением", называемых domain model (2).

I>>>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
G>>Непонятные для мня слова какие-то.
I>Конечно непонятные. Ты хочешь функций, а надо начинать с терминов, определений и базовых понятий.
Не нужно. Скажи что на входе, что на выходе и как оно преобразуется (на пальцах).

I>>>Тебе ничего из этого непонятно, правда ?
G>>Ага.

I>А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.
Ты не дал пример функции, ты назвал несколько непонятных слов из непонятной же предметной области.
Ты как пользователь программы человеческим языком можешь сказать что ты хочешь получить\увидеть?

I>>>У меня этого почти никогда не было, за 10 лет
G>>А как ты можешь узнать что ты вообще делаешь что-то полезное?

I>Выпытываю у людей, чего же они хотят и предлагаю решения. Иногда спеки таки бывают, но часто это ничего не означает.
То есть тыки собираешь требования\пожелания пользователей?



I>>>Только потому, что кастомер часто вообще не имеет представления о программировании.
G>>И что?
I>Он не может сформулировать задание толком.
А ему не надо формулировать задание, ему надо свои пожелания сказать.

G>>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.
I>Эванс в книге именно это и демонстрирует.
Ага, только в обратном порядке

I>>>Это не интересно. Фигуры всякие это для школьников.
G>>Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.
I>Разве чьи то фигуры и датчики Буча говорят что либо про книгу Эванса ?
Это мы от темы отошли, эванс не при чем.

I>>>А он и не утверждает, что все задачи должны решаться через DDD.
G>>Ну а какие должны?
I>Я еще не прочел всю книгу
А я два раза прочел, нету там. Чем дальше тем неинтереснее. У меня осталось ощущение что меня кинули, так как ответов на "вопрос почему стоит использовать DDD" я не нашел.

G>>А применимость для сложных задач не удалось пока никому доказать. Особенно не для задач моделирования.
I>Что значит доказать применимость ?
Доказать что некоторых подход дает преимущество по сравнению с другими подходами.

I>В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.
Когда модель давно существует и её применимость доказана это одно. А когда кто-нить просто выдумывает эту модель — совсем другое.

I>Просто модели бывают разными, вот и всё.
В первую очередь задачи бывают разными. Я вот недавно сталкивался с тремя вариантами задач составления расписаний. Но учитывая что в разных прогараммах расписания с разными целями использовались получились совершенно непохожие друг на друга куски кода.

Здравствуйте, gandjustas, Вы писали:

I>>В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?
G>"Бухучет" это уже готовая модель вообще любого учета. Очень желательно не изобретать свои модели, а использовать то что проверено временем.

А где взять готовую для любой другой области ? А между тем Эванс отвечает именно на этот вопрос.

I>>Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.
G>Так пусть заказчик оплатит обучение на ускоренных курсах инженеров печатных плат. Вообще заказчик обычно платит за решение своих проблем, а не решение проблем разработчиков ПО.

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

I>>Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.
G>Такс, уже пошли по кругу... Я вот утверждаю что не надо "вникать", чаще всего достаточно того что сообщает потенциальный пользователь. А если "бизнес" заказчика сложен, то появляется дополнительный слой аналитиков, которые могут рассказать это все гораздо лучше.

Эванс отвечает и на этот вопрос

I>>По твоему это натягивать функции на модель ?
G>Именно, зачем было заранее создавать модель, тем более в коде. Любой написанный код стоит денег и ограничивает "пространство маневра". Лучше код не писать, или писать такой чтобы его без проблем можно было выкинуть. Всеобъемлющая Domain Model как раз полная противоположность.

А где ты увидел что он заранее модель в коде создаёт ? Скажи номер страницы

I>>Чушь. Диалог прочти то, там где речь про прозванивание.
G>А до прозванивания что? Там же тоже диалоги есть.

Цитирую "По мере обсуждения того, что должна делать программа я начал рисовать схемы сам"

I>>В первой главе — возможно.
G>А в последующих тем более. Там он технические аспекты рассматривает в основном.

Не согласен. Ты книгу читаешь или отрывки в интернете ищешь ?

I>>"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."
G>Да я не против, пусть модель создают. Но эванс пытается модель создавать опираясь не на функции, а на "предметную область" (1), реализовывать модель в коде в виде классов с "поведением", называемых domain model (2).

Функции никуда не деваются. Я же цитировал. Еще раз что ли процитировать ?

I>>Конечно непонятные. Ты хочешь функций, а надо начинать с терминов, определений и базовых понятий.
G>Не нужно. Скажи что на входе, что на выходе и как оно преобразуется (на пальцах).

Что бы описать входы и выходы, ужны термины, определения, базовые понятия.

I>>А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.
G> Ты не дал пример функции, ты назвал несколько непонятных слов из непонятной же предметной области.

Я дал пример именно функции, так как кё понимают кастомеры.

G>Ты как пользователь программы человеческим языком можешь сказать что ты хочешь получить\увидеть?

Все пользователи имеют специальное инженерное образование в области телекоммуникаций и программировать считай не умеют.

I>>Выпытываю у людей, чего же они хотят и предлагаю решения. Иногда спеки таки бывают, но часто это ничего не означает.
G>То есть тыки собираешь требования\пожелания пользователей?

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

I>>Он не может сформулировать задание толком.
G>А ему не надо формулировать задание, ему надо свои пожелания сказать.

В каком виде ты хочешь пожелания ? Ты хоть пример покажи.

G>>>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.
I>>Эванс в книге именно это и демонстрирует.
G>Ага, только в обратном порядке

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

I>>Что значит доказать применимость ?
G>Доказать что некоторых подход дает преимущество по сравнению с другими подходами.

Ну так это книгой не докажешь.

I>>В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.
G>Когда модель давно существует и её применимость доказана это одно. А когда кто-нить просто выдумывает эту модель — совсем другое.

Разумеется. Если ты создаешь модель, главное что бы она позволяла задачи решать и могла эволюционировать. Потом можно и функциональный дизайн вывести, но начать с этого когда ты не знаешь области просто невозможно.

G>В первую очередь задачи бывают разными.

А еще бывает много задач в одной программе, а модель будет одна.

Здравствуйте, Ikemefula, Вы писали:

Хммм... может это обсуждение в отдельную ветку вынести? А то топикстартера щас окончательно запутаем

Или вообще закрыть — спорить можно до бесконечности, каждый в книжках видит исключительно своё и остальных слушать не желает категорически

Здравствуйте, perekrestov, Вы писали:
P>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>Тогда как эта сущность должна получать на него ссылку?
У меня эта сущность не будет взаимодействие с таким сервисом.

P>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .


P>

P>Customer customer;
P>// тут получили ссылку на него каким-то образом.

P>Product p;
P>// получили ссылку на товар

P>customer.Buy(p);
P>

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

  interface IPayementService 
  {
       void Buy(Customer buyer, Product product);
  }

Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.


P>У меня сложилось такое ощущение, что многие пытаются выносить более-мение сложную логику в бизнес сервисы из сущностей, т.к.
P>Но ведь это приводит к анимичной модели... А хочется все-таки понять как добиться на практике того, о чем говорит Эванс.
Книга Эванса достаточно абстрактная штука, нельзя её воспринимать буквально. Лучше почитайте современные блоги, статьи по DDD.

Здравствуйте, perekrestov, Вы писали:

P>Здравствуйте, Aviator, Вы писали:


P>>>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
A>>Сурово
P>Вроде как нормально
Что нормального?

P>Domain Driven Design and Development In Practice

P>

P>Dependency Injection

P>DI is a great way to move the configuration and dependency code out of the domain objects. Also, the design dependency of domain classes on Data Access Object (DAO) classes and service classes on domain classes makes DI a "must have" in DDD implementation. DI facilitates a cleaner and loosely coupled design by injecting the other objects such as Repositories and Services into Domain Objects.

P>In the sample application, the service object (FundingServiceImpl) uses DI to inject the Entity objects (Loan, Borrower and FundingRequest). Also, Entities reference Repositories via DI. Similarly, other Java EE resources like DataSource, Hibernate Session Factory and Transaction Manager are injected into Service and Repository objects.

Помещать доступ к данным, даже через интерфейс в доменный объект ... В итоге получаем огромные сущности с набором данных и кучей логики внутри. Не забываем кстати, что логика меняется чаще данных. И вообще, если очень хочется, что бы триггером начала обработки был вызов метода доменного объекта, то тогда уж domain events. А если по простому, то сложные действия лучше делать через набор служб, которые переколбасят доменные объекты как нужно.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:
P>>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>>Тогда как эта сущность должна получать на него ссылку?
A>У меня эта сущность не будет взаимодействие с таким сервисом.

P>>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
A>А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .


P>>

P>>Customer customer;
P>>// тут получили ссылку на него каким-то образом.

P>>Product p;
P>>// получили ссылку на товар

P>>customer.Buy(p);
P>>

P>>(пример с покупкой я вытянул с головы).
A>У вас слой служб перемешивается с сущностями, что не очень здорово. Я бы сделал
A>

A>  interface IPayementService 
A>  {
A>       void Buy(Customer buyer, Product product);
A>  }
A>

А еще лучше иметь интерфейс

interface IPayementService 
{
     void Buy(int cutomerId, int productId);
}

A>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.

Было смешивание слоя служб и сущностей, а стало смешение инфраструктуры и сущностей.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:
P>>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>>Тогда как эта сущность должна получать на него ссылку?
A>У меня эта сущность не будет взаимодействие с таким сервисом.

P>>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
A>А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .

A>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.
Я также о них думал....
В той статье, на которую я раньше ссылался, автор, вообще, советует, что если у нас логика затрагивает более одной сущности (даже не aggregate root), то нужно выносить
эту логику в бизнес-сервис. Но, как я понял, инъекция в Domain Objects вполне приемлимый вариант.
BTW, Довольно редко я видел, чтобы более-менее сложная логика затрагивала только одну сущность. Следуя этой логике мы будем иметь bloated services, что также не очень хорошо.
У меня от всего этого голова кругом идет.
Из всего, что я прочитал, я понял что следует находить компромис: максимально всю логику домена помещать в сущности, но если не можем туда ее поместить, то помещаем в сервисы.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:

P>>Здравствуйте, Aviator, Вы писали:



P>>In the sample application, the service object (FundingServiceImpl) uses DI to inject the Entity objects (Loan, Borrower and FundingRequest). Also, Entities reference Repositories via DI. Similarly, other Java EE resources like DataSource, Hibernate Session Factory and Transaction Manager are injected into Service and Repository objects.
P>>[/q]
A>Помещать доступ к данным, даже через интерфейс в доменный объект ... В итоге получаем огромные сущности с набором данных и кучей логики внутри. Не забываем кстати, что логика меняется чаще данных. И вообще, если очень хочется, что бы триггером начала обработки был вызов метода доменного объекта, то тогда уж domain events. А если по простому, то сложные действия лучше делать через набор служб, которые переколбасят доменные объекты как нужно.
Возникают у меня сомнения, что данные нужно отделять от поведения, даже несмотря на упомянутую вами разницу в жизненных циклах данных и поведения.

Данные все-таки у вас в сторадже хранятся. Они как хранились так и будут храниться.
А модель, которая изменяется и должна уметь изменяться, и которую вы постоянно совершенствуете является моделью реального мира (если так ее можно назвать).
Соотв., я пока не увидел причин отделять поведение от сущностей, т.к. сущности это еще не сами данные. Да мы их маппим на данные (ORM), но это еще не повод "цементировать" их
и делать, так сказать "readonly".

А нет ли у вас полезных ссылок на статьи о DDD. Уж очень хочется разобраться

Спасибо.

Здравствуйте, gandjustas, Вы писали:
P>>>(пример с покупкой я вытянул с головы).
A>>У вас слой служб перемешивается с сущностями, что не очень здорово. Я бы сделал
A>>

A>>  interface IPayementService 
A>>  {
A>>       void Buy(Customer buyer, Product product);
A>>  }
A>>

G>А еще лучше иметь интерфейс

G>

G>interface IPayementService 
G>{
G>     void Buy(int cutomerId, int productId);
G>}
G>

Это уже на другом уровне.

A>>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.

G>Было смешивание слоя служб и сущностей, а стало смешение инфраструктуры и сущностей.
Да, но службы и сущности плодятся и меняются. А брокер один и меняется редко. Собственно это вопрос компромисса, идеального решения нет.

Здравствуйте, gandjustas, Вы писали:

G>Так не стоит делать. Эванс мягко говоря обманывает. Если посмотреть примеры приложений в стиле DDD, то там всегда существует некоторый слой, где данные отделены от методов.

А можете привести примеры? поглядеть хочется.)

Здравствуйте, michael_isu, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Так не стоит делать. Эванс мягко говоря обманывает. Если посмотреть примеры приложений в стиле DDD, то там всегда существует некоторый слой, где данные отделены от методов.

_>А можете привести примеры? поглядеть хочется.)

http://dddsample.sourceforge.net/