Продолжил описание методики проектирования в новой статье:

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

В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.

У автора есть веские основания для такой рекомендации: любая техническая система создаётся для выполнения каких-то полезных функций. Если она их не выполняет, то такая система не нужна. Согласитесь, мало кому в быту будет полезен стул со сломанными ножками. Просто потому что на нём невозможно сидеть. В программной индустрии точно также. Если программа не делает нечто полезное, её можно удалить с компьютера, чтобы она не занимала место.

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

Дальше>>

Опять-таки интересуют мнения, комментарии, замечания и т.д.

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

КЛ>Рассмотрим эту процедуру на примере проектирования графического редактора.

КЛ>Интересует мнение коллег.

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

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

Представь себе — все вещи, которые используются в КорелДро, известны заранее — контуры, фигуры и тд.

Поэтому и получается такое удобное проектирование, как ты расписал.

Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.

Представь себе, это есть не всегда. Функции всегда описываются в _терминах_ предметной модели.

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

Т.е. имеем в наличии итерационный процесс и здесь пока еще про классы не было ни слова.

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

КЛ>Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:
КЛ>"Спроектируйте игру для девочек 4 – 8 лет".

А вы не теряйтесь

девочка 4-8 дет → клавиатура
 ↑                 ↓
монитор         ← игра

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

Мне кажется, совершенно напрасно ожидать описания процесса проектирования в одном посте. Слишком уж объёмна и многогранна эта тема.

Тем не менее, и о работе с заказчиком, и о разбиении требований на кластеры и об уточнении приоритетов я уже кое-что написал.

S>Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску):
Об общении с заказчиком и выявлении целей немного написано здесь.

S>Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу
О разбиении задачи на подзадачи и об уточнении приоритетов написано здесь и здесь.

S>В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво
Общий взгляд на процесс проектирования (что называется, с "птичьего полёта") изложен здесь.

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

Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.

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

Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.

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

Получается стройная и логичная картина:

class Figure;
class Rectangle : public Figure;
class Ellipse   : public Figure;
class Triangle  : public Figure;

К сожалению, она не позволяет создать редактор, который хоть в какой-то мере удовлетворяет потребностям пользователя.

Дальше >>

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

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

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

1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет.
2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено.
3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.

ЗЫ. Пока писал понял две вещи. Графический редактор слишком сложен для иллюстрации всех принципов, лучше навигационную систему брать. Наиболее интересно будет показать процесс проектирования (и всего остального) в рамках существующей методологии, будь то RUP, MSF или SCRUM.

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

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

I>>>Я говорю немного другое. Модель нужна для описания функций.
G>>Ну бред же, я тебе в параллельном треде приводил описание функции без определения понятий.
I>Это потому, что модель была известна неявно.
Это ты придумал.

I>>>Пока у тебя в голове нет понятия X, а только слово X, никакой задачи про X ты не решишь.
G>>Решу. Мне для этого не нужно понятие X, мне для этого нужны некоторые свойства X и не более того.
I>То есть, тебе не нужно полное знание о X, тебе нужна упрощенная модель X, свойств которой достаточно для решения задачи.

Модель — некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования (опуская несущественные свойства, в которых он может отличаться от прототипа).

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

Эванс (и ты тоже), предлагает сначала найти эти самые объекты, придумать им свойства, а потом накручивать на это функции.
Я предлагаю идти в обратном порядке.

Эванс честно признается что модель надо перерабатывать в процессе разработки программы. Я же говорю что не надо тратить силы на модель пока не появится досточно сведений чтобы сгруппировать свойства по конкретным сущностям.


I>Хочешь или не хоешь — это модель и если она позволяет решить какую то задачу, то она соответствует предметной области в контексте этой задачи.
Это ты уже обманывать пошел. В первую очередь себя.
Предметная область — то с чем работает заказчик, модель этой предметной области (см выше) — некоторое упрощение, реализованное в виде кода в нашем случае.
Твое утверждение "если модель позволяет решить задачу, то она соответствует предметной области" это попытка сделать хорошую мину при плохой игре.

I>>>Можно и с функциональным подходом уйти куда угодно.
G>>А вот нельзя. Функции "естественным" образом ведут к решению задачи. Реализация всех функций, полученных из всех требований? гарантирует что система делает именно то что сказал пользователь.
I>Пока что ты показал, что для решения задачи тебе надо уточнить модель области.
Ссылку дашь? Тебе привиделось.

G>>А вот если ты начинаешь с моделирования предметной области, то такой гарантии нет.
I>Если только моделировать эту область ради моделирования то так и будет.
А с какой целью делается моделирование предметной области у того же эванса, до того как он рассматривает конкретные функции?

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

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

I>>У заказчика. Без них он к тебе не пойдет. Что бы понять, что он от тебя хочет, тебе надо начинать с модели предметной области. Грубо говря — начать вникать в его специфику.
G>То есть сначала ты все таки получишь от заказчика задачи, а потом будешь троить модель предметной области?

Конечно. Если у заказчика задач не появится, с чего бы ему к разработчику идти ?

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

Ты уже показал, как можно описать функции не зная модели

Пока ты не скажешь мне хотя бы приблизительно, что такое Cost Based Mesh Design для SONET, твоим словам верить нельзя.

Если тебе не нужны ни термины, ни модель — покажи это на деле, задача не сложнее той что c Ethernet.

Но ты уже сказал, что ничего не понятно.

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

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

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

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

Те самые.

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

Одних данных мало. Кто будет за тебя функционал разрабатывать ? Будешь к заказчику бегать каждые пять минут ?

G>Я говорю про "модель предметной области по эвансу", а не про модель вообще.

Нет никакой специальной модели по эвансу.

G>Мы же всетаки код пишем, нам нужен формальный подход к этому процессу.

Вот и он говорит про это.

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

Просто возьми и перечитай.

G>>>А вот тут DDD сосет как промышленный пылесос, потому что создает сложности на пустом месте.
I>>Не знаю кто чего сосёт, но ты пока проделал ровно то же что и Эванс в первой главе например. Только у него это ДДД, а у тебя "ДДД сосёт".
G>Где это я построил модель предметной области в виде диаграмм классов со связями?

А ты прочти внимательно диалог.

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

А когда он говорит про прозванивание цепи, это что по твоему ?

G>Не надо мне приписывать то что я не делаю.

Да ты сам не знаешь чего делаешь

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

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

I>>Предположим, я ничего не знаю про сайты и тд.

I>>Вопрос — что такое сайт про который ты говоришь ? У меня на бумаге уже строится модель — квадратик, с подписью "сайт ?" и стрелочка ведет пока в троеточие.

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

Я не понимаю что значит слово "сайт". Что это такое или где можно узнать это ?

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

I>>Зачем ? Это сделал Лебедев, только задом наперёд.
G>Так сделай ты, как считаешь правильно.

Ага, и с сайтом, и с редактором, а ты будешь в сторонке курить ?

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

I>Я не понимаю что значит слово "сайт". Что это такое или где можно узнать это ?

Ты путаешь предметную область заказчика с областью твоей компетенции, как программиста. Если ты не умеешь создавать сайты, то, следовательно, ты не являешься компетентным web-девелопером.

Кстати, критерий компетентности — это не знание определения понятия сайт, а именно умение разрабатывать сайты.

I>Ага, и с сайтом, и с редактором, а ты будешь в сторонке курить ?
Пока что ты не привёл ни одного рабочего примера, иллюстрирующего твой подход. А как известно, практика — критерий истинности.

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

КЛ>>Кстати, критерий компетентности — это не знание определения понятия сайт, а именно умение разрабатывать сайты.
I>Ценное замечание, К.О. Как оно относится к нынешней беседе ?

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

Отсюда вывод: Первичны задачи и умение их решать (т.е. действия), а не познания в предметной области.

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

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

А построение всеобъемлющей модели предметной области — задача дорогостоящая и неподъёмная в рамках обычного бюджета.

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

I>У меня нет никакого "моего" подхода. Есть подход который изложен в книге DDD Эрика Эванса.
I>Хочешь рабочий пример, смотри первоисточник — http://dddsample.sourceforge.net/

Если ты читал эту книгу, то, наверное, можешь изложить какой-нибудь пример из неё в паре-тройке абзацев. Я всё-таки беседую с тобой, а не с Эриком Эвансом. И если ты выступаешь в защиту его подхода, то, наверное, можешь привести подтверждённые примерами аргументы.

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

КЛ>>>Кстати, критерий компетентности — это не знание определения понятия сайт, а именно умение разрабатывать сайты.
I>>Ценное замечание, К.О. Как оно относится к нынешней беседе ?

КЛ>Отсюда вывод: Первичны задачи и умение их решать (т.е. действия), а не познания в предметной области.

Вообще говоря первичность задач никто и не оспаривал. Есть задача — кастомер идет к девелоперу. Нет задачи — не идет к девелоперу.

КЛ>Другой вывод: Программисту не стоит вникать в предметную область клиента более, чем требуется для решения задач клиента. У программиста вполне конкретная задача — разработать программу, а не затмить клиента в области его экспертизы.

Предметная область есть у задачи. А чем занят клиент — дело десятое. Может, он спец по порнографии, но ему понадобился проектировщик оптических сетей, что бы забабахать мега-сеть, что бы его порно мега-скачивалось ? В этом случае его порно никак не влияет на предметную область задачи — проектирование оптических сетей.

Еще раз — предметная область у _задачи_.

КЛ>Рекомендация: Проектирование программы следует начинать не с изучения предметной области, а с изучения проблем клиента. Вникать в предметную область нужно лишь по мере необходимости — для уяснения сформулированных проблем.

Изучение проблемы клиента и есть погружение в предметную область задачи.

А рекомендации своему папе давай.

КЛ>А построение всеобъемлющей модели предметной области — задача дорогостоящая и неподъёмная в рамках обычного бюджета.

А кто кроме тебя говорит про всеобъемлющую модель предметной области ?

Покажи цитатой, где ты уведел "всеобъемлющую модель" в моем исполнении.

КЛ>Если ты читал эту книгу, то, наверное, можешь изложить какой-нибудь пример из неё в паре-тройке абзацев. Я всё-таки беседую с тобой, а не с Эриком Эвансом. И если ты выступаешь в защиту его подхода, то, наверное, можешь привести подтверждённые примерами аргументы.

Не, хватит с меня одного gandjustas, которому надо по пять раз указывать на "прозванивание".

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

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

I>>Я не понимаю что значит слово "сайт". Что это такое или где можно узнать это ?
G>Ну вот http://rsdn.ru это сайт, и http://gandjustas.blogspot.com тоже сайт. (я вот честно определения не знаю поэтому привожу примеры)

Значит, ты имеешь ввиду именно веб сайт (в квадратике сайт надпись меняется на веб-сайт). Этот сайт должен показывать картинки, какие то контакты и новости. Правильно ? (в модели появляется еще три квадратика с соответствующими надписями).

Что за контакты и что за новости ?

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

I>>>>Зачем ? Это сделал Лебедев, только задом наперёд.
G>>>Так сделай ты, как считаешь правильно.

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

Не, это слишком долго и точно не для форума. Кроме брукса у меня есть чего читать

Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:

"Спроектируйте графический редактор".
"Спроектируйте игру для девочек 4 – 8 лет".
"Спроектируйте GPS-навигационную систему для мобильного телефона".

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

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

1) выполнить декомпозицию задачи на подзадачи;
2) оценить объём полученных подзадач;
3) составить план работы, упорядочив подзадачи во времени и распределив их между участниками команды.

Рассмотрим эту процедуру на примере проектирования графического редактора.

Интересует мнение коллег.

Мне показалось, или суть процедуры сводится к построение трех квадратиков "Ввод"→ "Обработка"→"Вывод"?
А в целом, на 3-х страницах это не описать. Целые книги посвящены сбору и анализу требованию, описанию прецендетов (что в общем-то оно и есть) и т.п.

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

LV>Мне показалось, или суть процедуры сводится к построение трех квадратиков "Ввод"→ "Обработка"→"Вывод"?
Можно начинать и с такой простой модели. Но важно потом продолжить и детализировать эти абстрактные действия дальше.

LV>А в целом, на 3-х страницах это не описать. Целые книги посвящены сбору и анализу требованию, описанию прецендетов (что в общем-то оно и есть) и т.п.
Полностью, конечно, всё не описать. Но можно описать подход.

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

КЛ>Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:

КЛ>"Спроектируйте графический редактор".
КЛ>"Спроектируйте игру для девочек 4 – 8 лет".
КЛ>"Спроектируйте GPS-навигационную систему для мобильного телефона".

Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску):
1 — ключевые понятия предметной области заказчика и связи между ними.
2 — _цели_ заказчика и связанные с целями требования.
В результате и я, и заказчик узнаём много нового

Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу

Софтинки, не удовлетворяющие сами по себе никаких целей заказчика (кроме "продать и заработать") разрабатывать куда сложнее. В команду на ведущие роли обязательно нужны дизайнер UI + эксперт по юзабилити + тонна прототипов + опыт подобных разработок.

В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво

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

КЛ>В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.
В каких именно?
Как я понимаю умные книжки, сначала выявляют кто будет пользоваться системой. Затем описываются сценарии (ну или преценденты), из которых выявляют модели предметной области. Потому уже при необходимости делают описания сценариев.

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

LV>Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>>В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.
LV>В каких именно?
Мейер "OOA&D"
Нельсон "DDD"

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

G>Мейер "OOA&D"
G>Нельсон "DDD"
Буч
Рамбо

Судя по названию OOA&OOD речь в книгах идет о проектирование архитектуры. Это следующий этап после сбора требований.

Про DDD ничего сказать не могу. Разве что процитировать wikipedia:

Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.

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

LV>Судя по названию OOA&OOD речь в книгах идет о проектирование архитектуры. Это следующий этап после сбора требований.

LV>Про DDD ничего сказать не могу. Разве что процитировать wikipedia:

LV>

LV>Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.

Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет.

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

G>Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет.
Может быть. Просто на мой взгляд автор (Кирилл Лебедев) пишет о достаточно очевидных вещах на достаточно примитивном уровне. Например, в описание прецендентов (хотя у него скорее процедуры описаны) должны быть указаны акторы. А их нет. Нет и цели. Ну и много чего другого.

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

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

G>>Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет.
LV>Может быть. Просто на мой взгляд автор (Кирилл Лебедев) пишет о достаточно очевидных вещах на достаточно примитивном уровне. Например, в описание прецендентов (хотя у него скорее процедуры описаны) должны быть указаны акторы. А их нет. Нет и цели. Ну и много чего другого.

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

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

КЛ>Здравствуйте, Sinix, Вы писали:

КЛ>Мне кажется, совершенно напрасно ожидать описания процесса проектирования в одном посте. Слишком уж объёмна и многогранна эта тема.

КЛ>Тем не менее, и о работе с заказчиком, и о разбиении требований на кластеры и об уточнении приоритетов я уже кое-что написал.

S>>Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску):
КЛ>Об общении с заказчиком и выявлении целей немного написано здесь.

S>>Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу
КЛ>О разбиении задачи на подзадачи и об уточнении приоритетов написано здесь и здесь.

S>>В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво
КЛ>Общий взгляд на процесс проектирования (что называется, с "птичьего полёта") изложен здесь.

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

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

G>Проблема в том что все эти части взаимосвязаны. По отдельности нельзя рассматривать сбор требований, выявление фич, проектирование, прототипирование и другие активности цикла разработки. Независимое выполнение этих этапов тут любят называть "waterfall" и очень сильно ругать.

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

К сожалению (или к счастью?), в реальной жизни практическую ценность носят именно инструментальные модели. Поэтому и приходится описывать методику проектирования по частям.

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

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

G>>Проблема в том что все эти части взаимосвязаны. По отдельности нельзя рассматривать сбор требований, выявление фич, проектирование, прототипирование и другие активности цикла разработки. Независимое выполнение этих этапов тут любят называть "waterfall" и очень сильно ругать.

КЛ>Нет смысла спорить, все эти вещи взаимосвязаны. Но если их описывать в одной статье, у нас получится не инструментальная, а описательная модель. Потому что иначе не получится справиться с объёмом материала, который придётся изложить.

КЛ>К сожалению (или к счастью?), в реальной жизни практическую ценность носят именно инструментальные модели. Поэтому и приходится описывать методику проектирования по частям.

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

Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Нет смысла спорить, все эти вещи взаимосвязаны. Но если их описывать в одной статье, у нас получится не инструментальная, а описательная модель. Потому что иначе не получится справиться с объёмом материала, который придётся изложить.
Ну вы-то даете без привязки одного к другому.

Модель это представление объективной реальности. Что вы вкладываете в термины инструментальной и описательной модели и в чем разницам между ними?

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

LV>Ну вы-то даете без привязки одного к другому.
Не согласен. Сначала был изложен общий взгляд на процесс проектирования, теперь — излагается детализация отдельных шагов.

LV>Модель это представление объективной реальности. Что вы вкладываете в термины инструментальной и описательной модели и в чем разницам между ними?

С точки зрения американского нейропсихолога Л. Сквайра термин "описательная модель" (или "декларативные знания") "означает, что человек имеет ясный и доступный отчет о своем опыте, чувство знакомства с этим опытом" (см. здесь).

"В отличие от декларативных знаний, человек, обладающий процедурными знаниями (инструментальная модель — К.Л.), знает, как нужно действовать" (см. здесь).

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

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

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

G>1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет.
G>2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено.
G>3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.

Разве здесь цель не указана?

Спасибо!

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

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

G>>1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет.
G>>2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено.
G>>3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.

КЛ>Разве здесь цель не указана?

Указана, но не видно почему создание целого редактора необходимо для достижения цели.

Надо не просто указать некоторые хотелки, а написать хотя бы небольшой vision проекта.

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

Опубликовал продолжение примера по проектированию графического редактора. Опять-таки, интересует мнение коллег.

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

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

Основная ошибка, допускаемая неопытными разработчиками, заключается в том, что они рассматривают упрощённые прецеденты. (Или же не рассматривают их вообще.) Чтобы построить полную функциональную модель, нужно изучать сложные юз-кейсы, взятые из реальной жизни.

Вернёмся к нашему примеру – "проектирование графического редактора для создания открыток".

Дальше >>

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

КЛ>Дальше >>

Отличная статья, ИМХО самая полезная из всего цикла. Хотелось бы побольше объем статьи, ссылки на удачные и неудачные примеры из книг\статей\форумов.

Единственное что не понравилось — избитый до невозможности пример с фигурами.


Кстати, перечитав весь цикл понял что лучше его в обратном порядке рассказывать. Как говорится ground-up, что соответствует росту квалификации разработчика.

G>Отличная статья, ИМХО самая полезная из всего цикла.

Спасибо

G>Хотелось бы побольше объем статьи, ссылки на удачные и неудачные примеры из книг\статей\форумов.

Посмотрите здесь.

G>Единственное что не понравилось — избитый до невозможности пример с фигурами.

Буду постепенно выкладывать и другие примеры.

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

G>>Хотелось бы побольше объем статьи, ссылки на удачные и неудачные примеры из книг\статей\форумов.
КЛ>Посмотрите здесь.
Уже смотрел.

Опубликовано продолжение серии статей:

Цель этапа проектирование классов – найти подходящие классы и определить требования к ним.

Цель этапа проектирование реализации – изобрести реализацию класса, удовлетворяющую требованиям к нему.

В предложенном мною подходе логика проектирования может быть выражена формулой:

Функциональная модель => Группы функций => Кандидаты в классы => Реализация

Полностью смотрите здесь.

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

I>Функции всегда описываются в _терминах_ предметной модели.
Бред. Функция: показать график прибыли.
Какая предметная тут область?

I>Если термины тебе неизвестны, то сначала строится модель, потом прорабатываются функции, потом детализируется модель, детализируются функции и тд и тд и тд.
Вроде как было в одной из статей. Да и я тебе говорил.
У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно.

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

I>Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.

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

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

В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях.

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

I>>Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.

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

А что т будешь в юзкейсы писать ? Слово "транспондер" или "проключение" тебе что нибудь говорит ?

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

Вот в этих терминах и описываются юз-кейсы и именно с этих терминов начинается модель предметной области.

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

КЛ>В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях.

Мне лень бегать по форуму и искать твои посты.

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

I>>Функции всегда описываются в _терминах_ предметной модели.
G>Бред. Функция: показать график прибыли.
G>Какая предметная тут область?

Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.

G>У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно.

Я тебе уже приводил пример. Ты ничего внятного ответить не смог. А были дадены и входы и выходы и даже функция.

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

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

I>>>Функции всегда описываются в _терминах_ предметной модели.
G>>Бред. Функция: показать график прибыли.
G>>Какая предметная тут область?
I>Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.
Тем не менее функциональность определена без намека на предметную область.

G>>У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно.
I>Я тебе уже приводил пример. Ты ничего внятного ответить не смог. А были дадены и входы и выходы и даже функция.
Ну если бы еще денег дал за то что я этим буду заниматься, тогда поговорили бы. А так — нет.

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

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

I>>>>Функции всегда описываются в _терминах_ предметной модели.
G>>>Бред. Функция: показать график прибыли.
G>>>Какая предметная тут область?
I>>Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.
G>Тем не менее функциональность определена без намека на предметную область.

Про то и речь — конь в вакууме. Слово вроде понятное, а что сделать надо — хз.

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

Ты вероятно привык работать со знакомыми тебе вещами.

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

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

G>Ты в защиту своего утверждения пока еще ничего не привел.

Было бы так просто с функциями, ты давно бы ответил на мой вопрос.

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

I>А что т будешь в юзкейсы писать ? Слово "транспондер" или "проключение" тебе что нибудь говорит ?

В этой и предыдущих статьях речь идёт о проектировании системы, а не об ознакомлении с предметной областью. Понятно, что в сложных случаях разработчику нужно понимать предметную область. По этой причине, составление словаря терминов предметной области я считаю делом полезным. Однако сам по себе словарь не поможет разработать архитектуру системы и, в том числе, не поможет найти кандидаты в классы. Т.к. архитектура системы (и, соответственно, классы) есть производная от функционала.

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

КЛ>>В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях.
I>Мне лень бегать по форуму и искать твои посты.

А искать и не нужно. Открываешь последний пост и находишь ссылки в начале.

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

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

Думаю, раз ты употребил "Различные учебники по ООП" стало быть не от фонаря было дело ?

Дай ссылку хоть на один учебник где такое написано ?

>мы бросились искать абстракции в предметной области

На самом деле ты ни в какую предметную область не бросался а взял абстракции от балды.

Плохая статья — выдумал миф и лихо расправился с ним.

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

КЛ>В этой и предыдущих статьях речь идёт о проектировании системы, а не об ознакомлении с предметной областью. Понятно, что в сложных случаях разработчику нужно понимать предметную область. По этой причине, составление словаря терминов предметной области я считаю делом полезным. Однако сам по себе словарь не поможет разработать архитектуру системы и, в том числе, не поможет найти кандидаты в классы.

"Словарь" является необходимым, но не является достаточным условием. Что бы было и необходимо и достаточно, надо этот "словарь" дополнить функциями.


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

Коментить в блоге мне не интересно, в блоге у тебя жиденькое обсуждение.

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

I>Думаю, раз ты употребил "Различные учебники по ООП" стало быть не от фонаря было дело ?
I>Дай ссылку хоть на один учебник где такое написано ?

Да вот хотя бы у Страуструпа в разделе "1.2.4 Пределы абстракции данных".

I>Плохая статья — выдумал миф и лихо расправился с ним.

Напиши лучше.

P.S.: Мнение, не подкреплённое аргументами, неинтересно.

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

I>>Думаю, раз ты употребил "Различные учебники по ООП" стало быть не от фонаря было дело ?
I>>Дай ссылку хоть на один учебник где такое написано ?

КЛ>Да вот хотя бы у Страуструпа в разделе "1.2.4 Пределы абстракции данных".

И где там хоть чтото похожее на "для графического редактора ключевой абстракцией является фигура" ? Читаем вместе "Пока считаем, что в системе могут быть такие фигуры: окружность (circle), треугольник (triangle) и квадрат
(square)."

Т.е. Страуструп берет абстрактный упрощенный пример прямо с потолка — в системе есть фигуры и надо с ними чтото делать. Он не утверждает, что эти классы есть ключевые абстрации для графического редактора.

Теперь — страшное :

6.4 Пример законченой программы

Рассмотрим программу рисования геометрических фигур на экране.

Графический редактор != программа для рисования геометрических фигур и по моему это очевидно

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

I>>Плохая статья — выдумал миф и лихо расправился с ним.

КЛ>Напиши лучше.
КЛ>P.S.: Мнение, не подкреплённое аргументами, неинтересно.

см. выше.

В последнем сообщении, где у тебя появились контуры всякие, ты таки подошел к тому, с чего начинают в DDD — контуры, кривые, сегменты, отрезки, векторы, опорные точки.

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

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

Потому лучше с неё и начинать и про это пишут в книгах по DDD.

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

I>Графический редактор != программа для рисования геометрических фигур и по моему это очевидно

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

Вся проблема ООП-подхода как раз и заключается в том, что он прекрасно работает на упрощённых примерах. Стоит только рассмотреть не упрощённый, а реальный пример, как внешне красивые ООП-решения превращаются в нечто невообразимое.

Взять тот же пример из Страуструпа. Если нужно нарисовать несколько фигур, то, согласен, наследование и полиморфизм рулят. Но стоит только попытаться добавить редактирование или же увеличить количество различных фигур, скажем, до 100 (как это сделано в рисовалке Microsoft Word'а), так вся красивость рушится.

Собственно, об этом я и пишу здесь.

Что касается классов фигур, то это общее место в книгах идеологов ООП. Вот цитата из книги Бертрана Мейера:

"Все классы, представляющие фигуры, являются наследниками отложенного класса FIGURE, среди стандартных компонентов которого имеются display (показать), hide (скрыть), translate (сдвинуть), rotate (повернуть), scale (масштабировать).

Безусловно, множество фигур должно быть расширяемым, позволяя разработчикам приложений (и, опосредованно, конечным пользователям графических средств) определять их новые типы. Мы уже видели, как это можно сделать: предоставить класс COMPOSITE_FIGURE, построенный с помощью множественного наследования из класса FIGURE и такого типа контейнера, как LIST [FIGURE]".

http://www.intuit.ru/department/se/ooad/14/3.html

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

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

I>>>>>Функции всегда описываются в _терминах_ предметной модели.
G>>>>Бред. Функция: показать график прибыли.
G>>>>Какая предметная тут область?
I>>>Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.
G>>Тем не менее функциональность определена без намека на предметную область.

I>Про то и речь — конь в вакууме. Слово вроде понятное, а что сделать надо — хз.
Да ну?
1)"Показать график" — как минимум нужен графический интерфейс, сразу возникают вопросы для уточнения: использовать excel или рисовать свои графики (сразу куча сопутствующих вопросов)
2)Нас интересует "прибыль". На самом деле неважно, можно просто X. Два варианта: X где-то явно хранится или вычисляется по другим данным. Если по другим, то по каким. Как эти данные попадают в систему?
В принципе отвечая на эти вопросы можно раскрутить всю систему, абсолютно не занимаясь моделированием предметной области.

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

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

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

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

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

КЛ>Вся проблема ООП-подхода как раз и заключается в том, что он прекрасно работает на упрощённых примерах. Стоит только рассмотреть не упрощённый, а реальный пример, как внешне красивые ООП-решения превращаются в нечто невообразимое.

Да ладно то

КЛ>Взять тот же пример из Страуструпа. Если нужно нарисовать несколько фигур, то, согласен, наследование и полиморфизм рулят. Но стоит только попытаться добавить редактирование или же увеличить количество различных фигур, скажем, до 100 (как это сделано в рисовалке Microsoft Word'а), так вся красивость рушится.

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

КЛ>Что касается классов фигур, то это общее место в книгах идеологов ООП. Вот цитата из книги Бертрана Мейера:

КЛ>"Все классы, представляющие фигуры, являются наследниками отложенного класса FIGURE, среди стандартных компонентов которого имеются display (показать), hide (скрыть), translate (сдвинуть), rotate (повернуть), scale (масштабировать).

Ну и что ? Если ты пишешь рисовалку геометрических фигур, то это _нормально_.

А какой пример имел ввиду Бертран Мейер я не знаю. Если он про редактор векторной графики, это одно. А если про рисовалку фигур — это совсем другое.

У тебя книга под рукой, про какую программу пишет Бертран Мейер ?

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

I>В последнем сообщении, где у тебя появились контуры всякие, ты таки подошел к тому, с чего начинают в DDD — контуры, кривые, сегменты, отрезки, векторы, опорные точки.
Если пытаться с этого начать, то к результату можно и не прийти.
Вот у тебя в голове появляются "сущности" вроде контуров, кривых, сегментов, отрезков, векторов, опорных точек?
Хотя ты такой же Domain Expert в рисовании в графическом редакторе, как и остальные.

I>Вобщем, ты показал что ходить можно сколько угодно и начинать с чего угодно, даже с функций, но мимо предметной области не пройдешь.
I>Потому лучше с неё и начинать и про это пишут в книгах по DDD.
Логика на грани фантастики.

Ты показываешь что A => B. Из функций можно получить модель (кстати не факт что эта модель будет хоть как-то соотвествовать предметной области).
Потом говоришь что B => A. То есть из какой-то модели можно получить функции для решения некоторой задачи.
Хотя именно эта импликация до сих пор никем не доказана. А на практике получается что начиная с моделирования предметной области можно уйти очень далеко от решения задачи.

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

G>2)Нас интересует "прибыль". На самом деле неважно, можно просто X. Два варианта: X где-то явно хранится или вычисляется по другим данным. Если по другим, то по каким. Как эти данные попадают в систему?
G>В принципе отвечая на эти вопросы можно раскрутить всю систему, абсолютно не занимаясь моделированием предметной области.

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

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

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

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

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

То есть, для того, что бы понять, надо сначала иметь эту модель в голове ? Как ты ловко сам себя проверг то

G>Я вообще к предметной области не привязываюсь.

Было бы возможно только с функциями работать, ты бы быренько накидал мне решение.

Вот смотри, фокус. Раньше было Cost Based Mesh Design для SONET, а сейчас "схема Ethernet-сети минимальной стоимости".

Что изменилось ? Изменилась предметная область и все термины тебе стали простыми и понятными — все понятия в этой формуле у тебя есть в голове.

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

Посему — модель области это необходимое условие, а если дополнить функциями, будет необходимое и достаточное условие для решения задачи.

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

I>>В последнем сообщении, где у тебя появились контуры всякие, ты таки подошел к тому, с чего начинают в DDD — контуры, кривые, сегменты, отрезки, векторы, опорные точки.
G>Если пытаться с этого начать, то к результату можно и не прийти.

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

G>Вот у тебя в голове появляются "сущности" вроде контуров, кривых, сегментов, отрезков, векторов, опорных точек?
G>Хотя ты такой же Domain Expert в рисовании в графическом редакторе, как и остальные.

Не такой же Я кое на чем специализировался последние 10 лет.

I>>Вобщем, ты показал что ходить можно сколько угодно и начинать с чего угодно, даже с функций, но мимо предметной области не пройдешь.
I>>Потому лучше с неё и начинать и про это пишут в книгах по DDD.
G>Логика на грани фантастики.

G>Ты показываешь что A => B. Из функций можно получить модель (кстати не факт что эта модель будет хоть как-то соотвествовать предметной области).
G>Потом говоришь что B => A. То есть из какой-то модели можно получить функции для решения некоторой задачи.

Я говорю немного другое. Модель нужна для описания функций. Пока у тебя в голове нет понятия X, а только слово X, никакой задачи про X ты не решишь. Но как только у тебя появится понятие X, даже возможно с неправильным названием Y, ты уже сможешь понимать описания функций.

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

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

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

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

G>>2)Нас интересует "прибыль". На самом деле неважно, можно просто X. Два варианта: X где-то явно хранится или вычисляется по другим данным. Если по другим, то по каким. Как эти данные попадают в систему?
G>>В принципе отвечая на эти вопросы можно раскрутить всю систему, абсолютно не занимаясь моделированием предметной области.

I>Более того — это и будет моделирование предметной области Потому что ты придешь к конкретной прибыли, к конкретным сущностям которые необходимы для рассчета. А в зависимости от предметной области структура будет совершенно разная.
I>Соответсвенно и функция "рассчитать прибыль" будет конкретная.
Тут ты сильно заблуждаешься.
Я приду к некоторой модели данных (ER-модели), совершенно необязательно она будет хоть как-то соответствовать предметной области.

Это только в задачах моделирования ER-модель будет полностью соответствовать предметной области.

G>>>>Ты все таки утверждаешь что модель предметной области первостепенна для все программ, а тебе говорят что функциональная модель важнее.
I>>>Вообще то я говорил, что модель предметной области не везде нужна, т.к. много очевидных ситуаций где можно пользоваться готовой моделью или даже вообще без модели работать.
G>>Вот, уже интереснее. Как определить когда можно "вообще без модели работать"?
I>Если совсем буквально, то никогда Разница в том, будешь ли ты её моделировать её явно или неявно или она придет в готовом виде тоже явно или не явно.
Ты неправ, см коммент выше.

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


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

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

I>Вот смотри, фокус. Раньше было Cost Based Mesh Design для SONET, а сейчас "схема Ethernet-сети минимальной стоимости".
Отлично. Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?
Ну просто по-русски скажи.

I>Что изменилось ? Изменилась предметная область и все термины тебе стали простыми и понятными — все понятия в этой формуле у тебя есть в голове.
На самом деле все изменилось.

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

Ты вообще не путай модель данных с которыми работает программа и модель предметной области. Зачастую бывает что некоторые сущности в предметной области являются частными случаями (конкретными наборами атрибутов) в модели данных.

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

I>Я говорю немного другое. Модель нужна для описания функций.
Ну бред же, я тебе в параллельном треде приводил описание функции без определения понятий.

I>Пока у тебя в голове нет понятия X, а только слово X, никакой задачи про X ты не решишь.
Решу. Мне для этого не нужно понятие X, мне для этого нужны некоторые свойства X и не более того.
Мне совершенно не нужно знать чему соответствует X в предметной области.



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

А вот если ты начинаешь с моделирования предметной области, то такой гарантии нет.

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

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

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

Вот задача — два велосипедиста едут навстречу друг другу, известны скорости и начальные точки.

Вопрос 1 — для решения этой задачи, нужна ли тебе модель велосипедиста более детальная чем по точке на оного с велосипедом и всей амуницией ?

Вопрос 2 — будет ли эта модель соответсвовать предметной области ?

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

Как выяснилось, мы с тобой читали разных Эвансов

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

Наоброт, это совершенно в тему.

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

Конечно — я утверждаю, что на одних функциях никуда не уедешь.

I>>Вот смотри, фокус. Раньше было Cost Based Mesh Design для SONET, а сейчас "схема Ethernet-сети минимальной стоимости".
G>Отлично. Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?
G>Ну просто по-русски скажи.

Заметь — как только ты увидел знакомые термины(предметная область!) у тебя уже появились конкретные вопросы и ты уточняешь именно модель предметной области — структуру и функции. Схема — структура+инфраструктура+топология. Минимальной стоимости можно достигнуть минимизируя совокупную стоимость решения — оборудование, кабели, работы по прокладке кабелей. Допустим, эксплуатационные расходы не интересуют — упростим задачу, что бы не флудить год или два кряду

И заметь — функция стоимости формулируется в терминах предметной области, которые тебе должны быть известны — оборудование, кабели.

Если ты не знаешь терминов, ты не сможешь построить модель.

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

I>>Что изменилось ? Изменилась предметная область и все термины тебе стали простыми и понятными — все понятия в этой формуле у тебя есть в голове.
G>На самом деле все изменилось.

Дык про то и речь. Я специально подбираю примеры что бы тебе видно было, с чем же ты борешься.

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

См. выше

G>Ты вообще не путай модель данных с которыми работает программа и модель предметной области. Зачастую бывает что некоторые сущности в предметной области являются частными случаями (конкретными наборами атрибутов) в модели данных.

Я и не путаю. Модель данных это ровно там часть модели предметной области, кторая необходима для вычислений.

Т.е. это срез модели на конкретный момент времени.

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

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

I>>Я говорю немного другое. Модель нужна для описания функций.
G>Ну бред же, я тебе в параллельном треде приводил описание функции без определения понятий.

Это потому, что модель была известна неявно.

I>>Пока у тебя в голове нет понятия X, а только слово X, никакой задачи про X ты не решишь.
G>Решу. Мне для этого не нужно понятие X, мне для этого нужны некоторые свойства X и не более того.

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

G>Мне совершенно не нужно знать чему соответствует X в предметной области.

И что с того ? Точка может быть моделью велосипедиста с велосипедом, рюкзаком, спицами и колбасой в желудке у велосипедиста.

Хочешь или не хоешь — это модель и если она позволяет решить какую то задачу, то она соответствует предметной области в контексте этой задачи.

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


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

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

G>А вот если ты начинаешь с моделирования предметной области, то такой гарантии нет.

Если только моделировать эту область ради моделирования то так и будет.

Точно так же если строить функциональную модель ради функциональной модели, можно уйти куда угодно.

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

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

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

I>Полного соответсвия никогда не будет. Во первых, по тому, что область развивается и понятия пополняются, уточняются, разделяются, устраняются и тд.
I>Во вторых, покрыть софтом даже малую часть всей известной на нынешний день какой либо области крайне сложно.
I>В третьих, если твоя ER-модель никак не будет соответсвовать области, то она абсолютно бесполезна и годится только для коней в вакууме.
Как раз ER-модель, сформированная в итоге развития системы, которая реализует все необходимые функции, более чем полезна. Она гораздо полезнее любой модели, которую можно придумать заранее (не учитывая функции).
А насколько на соответствует предметной области меня вообще не интересует. Я ведь занимаюсь тем что решаю проблемы пользователей, а не моделирую предметную область.


I>Вот задача — два велосипедиста едут навстречу друг другу, известны скорости и начальные точки.
А где задача то?

I>Вопрос 1 — для решения этой задачи, нужна ли тебе модель велосипедиста более детальная чем по точке на оного с велосипедом и всей амуницией ?
I>Вопрос 2 — будет ли эта модель соответсвовать предметной области ?
Ты задачу не привел. Пусть себе едут.

Запомни. Программа решает проблемы пользователей.

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

I>>>Было бы возможно только с функциями работать, ты бы быренько накидал мне решение.
G>>См коммент выше, ты формулируешь задачу в терминах предметной области, я тебе дважды говорил что я не буду в этих терминах разбираться.
G>>Ты продолжаешь стоять на своем.
I>Конечно — я утверждаю, что на одних функциях никуда не уедешь.
Интересно сколько раз я тебе сказал что у функций есть входные и выходные данные?
Множество всех входных данных образуют некоторую модель (ER-модель). Это я тоже говорил.
Полученная модель данных может не соответствовать модели предметной области. Да и не нужно это.
Ты что пытаешь доказать?

I>>>Вот смотри, фокус. Раньше было Cost Based Mesh Design для SONET, а сейчас "схема Ethernet-сети минимальной стоимости".
G>>Отлично. Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?
G>>Ну просто по-русски скажи.

I>Заметь — как только ты увидел знакомые термины(предметная область!) у тебя уже появились конкретные вопросы и ты уточняешь именно модель предметной области — структуру и функции.
Ты заблуждаешься, я не увидел незнакомых терминов, которые мешают вести диалог.

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

I>И заметь — функция стоимости формулируется в терминах предметной области, которые тебе должны быть известны — оборудование, кабели.
С чего ты взял? Мне достаточно знать что у них есть стоимость. Пусть они для общности будут X и Y. Даже лучше просто X, я не вижу разницы между "оборудование" и "кабели" на данном уровне детализации.

I>Если ты не знаешь терминов, ты не сможешь построить модель.
А мне не нужна модель По крайней мере на данном уровне.

I>Буквально класса "кабель" в твоей программе может и не быть но термины придется осводить до минимально необходимого уровня детализации.
А может и не придется

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

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

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


G>>Ты вообще не путай модель данных с которыми работает программа и модель предметной области. Зачастую бывает что некоторые сущности в предметной области являются частными случаями (конкретными наборами атрибутов) в модели данных.
I>Я и не путаю. Модель данных это ровно там часть модели предметной области, кторая необходима для вычислений.
Расскажи это эвансу. Для него модель предметной области это в первую очередь некоторый словарь, который позволяет общаться с заказчиками. Если он будет неполный или неточный с точки зрения заказчиков, то это уже не будет моделью предметной области по эвансу никак.

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

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

I>>Во вторых, покрыть софтом даже малую часть всей известной на нынешний день какой либо области крайне сложно.
I>>В третьих, если твоя ER-модель никак не будет соответсвовать области, то она абсолютно бесполезна и годится только для коней в вакууме.
G>Как раз ER-модель, сформированная в итоге развития системы, которая реализует все необходимые функции, более чем полезна. Она гораздо полезнее любой модели, которую можно придумать заранее (не учитывая функции).

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

G>А насколько на соответствует предметной области меня вообще не интересует. Я ведь занимаюсь тем что решаю проблемы пользователей, а не моделирую предметную область.

Моделировать нужно ровно настолько, сколько требуют задачи пользователя. Меньше — какие то задачи не решишь. Больше — дороже решение.

I>>Вот задача — два велосипедиста едут навстречу друг другу, известны скорости и начальные точки.
G>А где задача то?

В школьном учебнике, бери любую про велосипедистов.

I>>Вопрос 1 — для решения этой задачи, нужна ли тебе модель велосипедиста более детальная чем по точке на оного с велосипедом и всей амуницией ?
I>>Вопрос 2 — будет ли эта модель соответсвовать предметной области ?
G>Ты задачу не привел. Пусть себе едут.

В школу ты не ходил ? Так и запишем.

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

Вообще то это я тебе показывал цитаты которые ты не хотел видеть, а не наоборот. Ты не показал ровно ничего из того, что я якобы не увидел

I>>Конечно — я утверждаю, что на одних функциях никуда не уедешь.
G>Интересно сколько раз я тебе сказал что у функций есть входные и выходные данные?
G>Множество всех входных данных образуют некоторую модель (ER-модель). Это я тоже говорил.
G>Полученная модель данных может не соответствовать модели предметной области. Да и не нужно это.

Полного соответсвия не нужно. Полное несоответсвие делает невозможным решение задач.

Что непонятно то ?

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

То есть про схему ты для понту спросил ?

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

И тебе опять нужна детализация модели предметной области

I>>И заметь — функция стоимости формулируется в терминах предметной области, которые тебе должны быть известны — оборудование, кабели.
G>С чего ты взял? Мне достаточно знать что у них есть стоимость. Пусть они для общности будут X и Y. Даже лучше просто X, я не вижу разницы между "оборудование" и "кабели" на данном уровне детализации.

Тебе надо не только знать стоимость, но и много чего еще. Например, тебе надо отличать их друг от друга и знать, какие у кого есть характеристики.

I>>Если ты не знаешь терминов, ты не сможешь построить модель.
G>А мне не нужна модель По крайней мере на данном уровне.

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

I>>Буквально класса "кабель" в твоей программе может и не быть но термины придется осводить до минимально необходимого уровня детализации.
G>А может и не придется

Придется, потому что у кабеля есть длина и есть специфика которая влияет на стоимость решения.

I>>Дык про то и речь. Я специально подбираю примеры что бы тебе видно было, с чем же ты борешься.
G>Это ты борешься, а я упрощаю себе жизнь. Буквально не делаю того что не нужно.

Не, ты просто оттягиваешь неизбежное и маскируешь это под разными словами вроде "ER-модель".

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

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

В старой задаче, про Cost Based Mesh Design для SONET для тебя все по прежнему глухо и тебе надо уточнять базовые понятия, что бы хотя бы начать задавать вопросы по функционалу.

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

Вот эти детали и есть модель предметной области.

G>Ты доказываешь повторением одних и тех же слов. Я же тебе на примере показываю обратное.

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

При чем недоумение и непонимание у тебя опять же ожидаемое

I>>Я и не путаю. Модель данных это ровно там часть модели предметной области, кторая необходима для вычислений.
G>Расскажи это эвансу. Для него модель предметной области это в первую очередь некоторый словарь, который позволяет общаться с заказчиками.

Эванс вобщем то это и говорит. У него модель данных и модель предментной области не тождественны.

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

Не будет. Минимальный набор слов в словаре — для описания модели данных. Максимальный — для описания всех функций системы.

Вот это — Эванс. А то что ты вычитал — фигня

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

Полностью владеть и не нужно, но определенный минимум ты будешь знать.

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

I>>>>Я говорю немного другое. Модель нужна для описания функций.
G>>>Ну бред же, я тебе в параллельном треде приводил описание функции без определения понятий.
I>>Это потому, что модель была известна неявно.
G>Это ты придумал.

Не придумал, а прочитал тобой написаное

G>

Модель — некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования (опуская несущественные свойства, в которых он может отличаться от прототипа).

G>Я говорю только о свойствах, не привязывая их к конкретной модели. Построение модели данных будет когда я соберу все свойства.

Читай свою же цитату — "свойства, существенные для целей конкретного моделирования"

G>Эванс (и ты тоже), предлагает сначала найти эти самые объекты, придумать им свойства, а потом накручивать на это функции.

Это какой то другой Эванс. Тот, которого я читаю, не придумывает, а выясняет путём дознания у заказчика.

G>Эванс честно признается что модель надо перерабатывать в процессе разработки программы. Я же говорю что не надо тратить силы на модель пока не появится досточно сведений чтобы сгруппировать свойства по конкретным сущностям.

Ты уже показал как это делаешь — уточняя модель

I>>Хочешь или не хоешь — это модель и если она позволяет решить какую то задачу, то она соответствует предметной области в контексте этой задачи.
G>Это ты уже обманывать пошел. В первую очередь себя.

Где ж обман ?

G>Предметная область — то с чем работает заказчик, модель этой предметной области (см выше) — некоторое упрощение, реализованное в виде кода в нашем случае.

Не просто упрощение, а "..., существенные для целей конкретного моделирования"

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

Читай свою же цитату. "свойства, существенные для целей конкретного моделирования"

Цель — решение задачи. Модель соответсвует предметной области в контексте цели, если содержит все существенное для это цели.

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

" Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?"

Ссылку ищи сам. Но можешь считать что этой фразы не было в обсуждении

I>>Если только моделировать эту область ради моделирования то так и будет.
G>А с какой целью делается моделирование предметной области у того же эванса, до того как он рассматривает конкретные функции?

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

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

Ты всего лишь держишь в уме нечто, чего пытаешься назвать то ER-моделью, то еще чем то.

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

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

I>>>Во вторых, покрыть софтом даже малую часть всей известной на нынешний день какой либо области крайне сложно.
I>>>В третьих, если твоя ER-модель никак не будет соответсвовать области, то она абсолютно бесполезна и годится только для коней в вакууме.
G>>Как раз ER-модель, сформированная в итоге развития системы, которая реализует все необходимые функции, более чем полезна. Она гораздо полезнее любой модели, которую можно придумать заранее (не учитывая функции).
I>При чем здесь это ? Если она нисколько не соответсвует предметной области то ни одну из задач пользователя ты не решишь.
Еще раз: соответствие полученной модели данных и модели предметной области меня не интересует. Меня интересует что модель данных полученная таким образом гораздо полезнее, чем модель предметной области, которую надо заранее строить.

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

Кратко задачи => модель != (в общем случае) модель предметной области
Ну как-бы первую импликацию ты и сам только что сказал, осталось тебе согласиться со вторым неравенством.

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

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

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

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

I>>>Я и не путаю. Модель данных это ровно там часть модели предметной области, кторая необходима для вычислений.
G>>Расскажи это эвансу. Для него модель предметной области это в первую очередь некоторый словарь, который позволяет общаться с заказчиками.
I>Эванс вобщем то это и говорит. У него модель данных и модель предментной области не тождественны.
Да ты что? Покажешь где он это говорит? Страница? О чем тогда все DDD?

>>Если он будет неполный или неточный с точки зрения заказчиков, то это уже не будет моделью предметной области по эвансу никак.
I>Не будет. Минимальный набор слов в словаре — для описания модели данных. Максимальный — для описания всех функций системы.
I>Вот это — Эванс. А то что ты вычитал — фигня
Ну так покажи в его книге это утверждение? У всех апологетов ddd я встречаю такое первый раз.

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

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

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

I>>>>>Я говорю немного другое. Модель нужна для описания функций.
G>>>>Ну бред же, я тебе в параллельном треде приводил описание функции без определения понятий.
I>>>Это потому, что модель была известна неявно.
G>>Это ты придумал.
I>Не придумал, а прочитал тобой написаное
Если модель была известно неявно, значит ты как-то прочитал мной ненаписанное.

G>>

Модель — некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования (опуская несущественные свойства, в которых он может отличаться от прототипа).

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

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

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

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

G>>Предметная область — то с чем работает заказчик, модель этой предметной области (см выше) — некоторое упрощение, реализованное в виде кода в нашем случае.
I>Не просто упрощение, а "..., существенные для целей конкретного моделирования"

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

I>Цель — решение задачи. Модель соответсвует предметной области в контексте цели, если содержит все существенное для это цели.
Классно, значит все таки задачи первостепенны и уж точно не надо начинать строить модель не имея всех задач.

Ты сам опроверг свое заявление отсюда

Автор: Ikemefula
Дата: 29.11.10

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

I>>>Пока что ты показал, что для решения задачи тебе надо уточнить модель области.
G>>Ссылку дашь? Тебе привиделось.
I>" Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?"
Это я промахнулся, надо было вопрос задавать как пользователь увидит эту "схему".

I>>>Если только моделировать эту область ради моделирования то так и будет.
G>>А с какой целью делается моделирование предметной области у того же эванса, до того как он рассматривает конкретные функции?
I>Для того, что бы понять что же за функции ему надо оформить.
Цитирую тебя же выше

Цель (моделирования) — решение задачи.

Задача (функции) должны быть определены до моделирования, а ты говоришь что моделирование делается для того чтобы понять функции.

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

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

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

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

I>>Не придумал, а прочитал тобой написаное
G>Если модель была известно неявно, значит ты как-то прочитал мной ненаписанное.

Прочитал ровно то что ты написал.

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

Обращаю твое внимание. Представь себе — это ключевой момент в определении модели.

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

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

Конечно может. Потому и Эванс и ты задаете вопросы тому, кто может дать ответ.

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

Модель данных это только срез который необходим для конкретных вычислений.

I>>Цель — решение задачи. Модель соответсвует предметной области в контексте цели, если содержит все существенное для это цели.
G>Классно, значит все таки задачи первостепенны и уж точно не надо начинать строить модель не имея всех задач.

Да, пока заказчик не пришел к тебе, ты про него ничего не знаешь.

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

G>Вобщем, ты показал что ходить можно сколько угодно и начинать с чего угодно, даже с функций, но мимо предметной области не пройдешь.
G>Потому лучше с неё и начинать и про это пишут в книгах по DDD.

Нет никакого опровержения Задачи — они для заказчика важны. А тебе надо в первую очередь понять заказчика. Вот здесь тебе нужна модель. А уже потом, когда ты начнешь понимать заказчика, только тогда сможешь функции описывать.


G>>>Ссылку дашь? Тебе привиделось.
I>>" Что есть схема? на основании чего она строится? Как достигнуть этой минимальной стоимости?"
G>Это я промахнулся, надо было вопрос задавать как пользователь увидит эту "схему".

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

G>

G>Цель (моделирования) — решение задачи.

G>Задача (функции) должны быть определены до моделирования, а ты говоришь что моделирование делается для того чтобы понять функции.

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

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

Никакого противоречия — все одно и то же.

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

В том то и дело. И модель ты строишь для того, что бы понять о чем речь.

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

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

Вообще то модель данных это только срез.

G>То есть до этого таки сначала нужны задачи?

У заказчика. Без них он к тебе не пойдет. Что бы понять, что он от тебя хочет, тебе надо начинать с модели предметной области. Грубо говря — начать вникать в его специфику.

G>То есть задачи являются необходимым условием для модели (любой)?

Конечно.

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

Чушь. Без модели ты вообще ничего сделать не можешь.

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

G>Кратко задачи => модель != (в общем случае) модель предметной области
G>Ну как-бы первую импликацию ты и сам только что сказал, осталось тебе согласиться со вторым неравенством.

Я не понял что ты здесь хотел сказать.

I>>Полного соответсвия не нужно. Полное несоответсвие делает невозможным решение задач.
G>А меня вообще это соответствие не интересует, понимаешь? Это лишняя для меня информация.

А нахрена ты уточняешь термины если тебя соответствие не волнует ?

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

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



I>>Вот эти детали и есть модель предметной области.
G>Ну если ты любые данные называешь предметной областью, то ты прав. А я не так называю и ты неправ

Предметная облсть это совокупность всех знаний. Модель — это часть необходимая для решения конкретной задачи.

I>>Эванс вобщем то это и говорит. У него модель данных и модель предментной области не тождественны.
G>Да ты что? Покажешь где он это говорит? Страница? О чем тогда все DDD?

Эванс функции никуда не выбрасывает. Модель данных не включает в себя функции И много чего еще не включает.

I>>Не будет. Минимальный набор слов в словаре — для описания модели данных. Максимальный — для описания всех функций системы.
I>>Вот это — Эванс. А то что ты вычитал — фигня
G>Ну так покажи в его книге это утверждение? У всех апологетов ddd я встречаю такое первый раз.

В первых двух главах он говорит про это.

I>>Полностью владеть и не нужно, но определенный минимум ты будешь знать.
G>Ты опять называешь "моделью предметной области" данные с которыми работает программа.

Вообще то функции никуда не девались

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

Не знаю кто чего сосёт, но ты пока проделал ровно то же что и Эванс в первой главе например. Только у него это ДДД, а у тебя "ДДД сосёт".

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

I>>>Цель — решение задачи. Модель соответсвует предметной области в контексте цели, если содержит все существенное для это цели.
G>>Классно, значит все таки задачи первостепенны и уж точно не надо начинать строить модель не имея всех задач.

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

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

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



G>>

G>>Цель (моделирования) — решение задачи.

G>>Задача (функции) должны быть определены до моделирования, а ты говоришь что моделирование делается для того чтобы понять функции.

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

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

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

А ты сразу начинаешь строить модель? Покажешь такой процесс на примере создания сайта?

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

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

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

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


G>>Кратко задачи => модель != (в общем случае) модель предметной области
G>>Ну как-бы первую импликацию ты и сам только что сказал, осталось тебе согласиться со вторым неравенством.
I>Я не понял что ты здесь хотел сказать.
Ботай матлогику.

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

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


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

I>>>Не будет. Минимальный набор слов в словаре — для описания модели данных. Максимальный — для описания всех функций системы.
I>>>Вот это — Эванс. А то что ты вычитал — фигня
G>>Ну так покажи в его книге это утверждение? У всех апологетов ddd я встречаю такое первый раз.
I>В первых двух главах он говорит про это.
Номер страницы, абзаца.


G>>Но это и не важно. Суть вопроса не в том что такое модель предметной области, а как ты с ней работаешь создавая программу.
G>>А вот тут DDD сосет как промышленный пылесос, потому что создает сложности на пустом месте.
I>Не знаю кто чего сосёт, но ты пока проделал ровно то же что и Эванс в первой главе например. Только у него это ДДД, а у тебя "ДДД сосёт".
Где это я построил модель предметной области в виде диаграмм классов со связями?
Эванс первые несколько абзацев уделяет модели предметной области, не говоря о функциях вообще.
Не надо мне приписывать то что я не делаю.

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

I>>Да, пока заказчик не пришел к тебе, ты про него ничего не знаешь.
I>>Как только он раскрыл рот, тебе надо строить модель предметной области, иначе ты вряд ли поймешь заказчика.
G>Это голословное утверждение тебе еще не удалось доказать. При любой попытке доказательства ты скатываешь к тому что сначала нужны функции, о чем тебе тут и говорят.

По моему очень неплохо получилось доказать, ты ведь так и не родил ничего для Cost Based Mesh Design для SONET и сказал что тебе непонятно ?

Дальше я скипнул, ибо стало скучно. Как сможешь родить что нибудь про Cost Based Mesh Design для SONET без знаний в предметной области, приходи.

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


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

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

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

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


I>>>Ага, с незнакомыми терминами ты ничего придумать не смог. Как только появились знакомые — сразу и вопросы конкретные появились.
G>>Конечно, мне не термины нужны, а данные с которыми работают алгоритмы.
G>>А ты зачем-то пытаешься терминами заменить понимание этих данных.
I>Одних данных мало.
С чего ты взял?

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

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

G>>Мы же всетаки код пишем, нам нужен формальный подход к этому процессу.
I>Вот и он говорит про это.
Он говорит о том что сначала рисуется модель (в прямом смысле). Потом берет одну из функций, не уточняя что на самом деле надо на входе и на выходе и пытается её натянуть на модель.

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

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

I>Все твои рассуждения сводятся примерно к следующим — можно написать программу для игры в шахматы, не зная правил игры в шахматы.

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

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

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

I>>>Да, пока заказчик не пришел к тебе, ты про него ничего не знаешь.
I>>>Как только он раскрыл рот, тебе надо строить модель предметной области, иначе ты вряд ли поймешь заказчика.
G>>Это голословное утверждение тебе еще не удалось доказать. При любой попытке доказательства ты скатываешь к тому что сначала нужны функции, о чем тебе тут и говорят.

I>По моему очень неплохо получилось доказать, ты ведь так и не родил ничего для Cost Based Mesh Design для SONET и сказал что тебе непонятно ?
I>Дальше я скипнул, ибо стало скучно. Как сможешь родить что нибудь про Cost Based Mesh Design для SONET без знаний в предметной области, приходи.
Ты кидаешься терминами, не пытаясь указать функции. Короче выкручивашься как можешь.

Последний вопрос. Ты счташь что надо заниматься построением предметной области до того как ты узнаешь какие функции требуются от программы или нет?
Однозначный ответ да или нет.

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

I>>По моему очень неплохо получилось доказать, ты ведь так и не родил ничего для Cost Based Mesh Design для SONET и сказал что тебе непонятно ?
I>>Дальше я скипнул, ибо стало скучно. Как сможешь родить что нибудь про Cost Based Mesh Design для SONET без знаний в предметной области, приходи.
G>Ты кидаешься терминами, не пытаясь указать функции. Короче выкручивашься как можешь.

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

G>Последний вопрос. Ты счташь что надо заниматься построением предметной области до того как ты узнаешь какие функции требуются от программы или нет?
G>Однозначный ответ да или нет.

Да, для того, что бы понять о чем речь. см пример выше

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

I>>Конечно, ведь есть хороший выход — дергать заказчика каждые пять минут на протяжении всей разработки.
G>А разве эванс не пишет тоже самое, называя представителей заказчика Domain Experts?

Для посмотрение модели так и нужно. А потом уже без этого можно ехать.

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

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

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

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

Спасибо за потраченое время.

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

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

I>>>По моему очень неплохо получилось доказать, ты ведь так и не родил ничего для Cost Based Mesh Design для SONET и сказал что тебе непонятно ?
I>>>Дальше я скипнул, ибо стало скучно. Как сможешь родить что нибудь про Cost Based Mesh Design для SONET без знаний в предметной области, приходи.
G>>Ты кидаешься терминами, не пытаясь указать функции. Короче выкручивашься как можешь.

I>Ты даже понять не можешь, что функция указана более чем явно и при этом утверждаешь что понимать и не нужно
Еще раз. Функция это входыне данные, выходные данные и некоторые преобразования над ними.
Ты не указываешь ни входных, ни выходных данных.

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

G>>Последний вопрос. Ты счташь что надо заниматься построением предметной области до того как ты узнаешь какие функции требуются от программы или нет?
G>>Однозначный ответ да или нет.
I>Да, для того, что бы понять о чем речь. см пример выше
Ок, вот тебе пример выше про сайт. Можешь взять пример из статьи Лебедева, про графический редактор.
Покажи как спроектировать то что нужно начиная с модели предметной области. Хотябы начни.

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

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

Смотри, насколько всё просто:

var SONET(1) = CostBasedMeshDesign(SONET(0));

Очевидно, что понятнее тебе не стало и тебе надо погружаться в предметную область.

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

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

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

I>>Да, для того, что бы понять о чем речь. см пример выше
G>Ок, вот тебе пример выше про сайт. Можешь взять пример из статьи Лебедева, про графический редактор.
G>Покажи как спроектировать то что нужно начиная с модели предметной области. Хотябы начни.

В таких простых примерах модель передается _неявно_. Она как правило всем известна и только поэтому никто не задумывается об этом как о модели.

В таких случаях думают только о конкретной модели данных, т.е. о срезе модели и о функциональной модель, т.е. обратно о срезе.

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

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

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

I>Смотри, насколько всё просто:
I>var SONET(1) = CostBasedMeshDesign(SONET(0));
I>Очевидно, что понятнее тебе не стало и тебе надо погружаться в предметную область.
Запомним это.

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

I>Пока что здесь слово сайт, которое обладает вполне конкретным смыслом. Этот смысл я и буду прояснять, вдруг, например, окажется, что сайт это не веб-сайт


I>Вот если это окажется "Веб-сайт" то это уже предполагает кое какие функции — показ контента в некоторой сети, предоставление некоторых возможностей и тд. Соответсвенно у меня сразу появляется N уточняющих вопросов, т.к. базовые сведения про веб-сайты у меня уже есть.
Ну давай свои вопросы.

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


I>>>Да, для того, что бы понять о чем речь. см пример выше
G>>Ок, вот тебе пример выше про сайт. Можешь взять пример из статьи Лебедева, про графический редактор.
G>>Покажи как спроектировать то что нужно начиная с модели предметной области. Хотябы начни.

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

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

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

Предположим, я ничего не знаю про сайты и тд.

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

Почти как у Эванса, только у него было два квадрата.

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

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

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

Зачем ? Это сделал Лебедев, только задом наперёд.

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

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

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

I>Предположим, я ничего не знаю про сайты и тд.

I>Вопрос — что такое сайт про который ты говоришь ? У меня на бумаге уже строится модель — квадратик, с подписью "сайт ?" и стрелочка ведет пока в троеточие.

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

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

I>Зачем ? Это сделал Лебедев, только задом наперёд.
Так сделай ты, как считаешь правильно.

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

I>>Я не понимаю что значит слово "сайт". Что это такое или где можно узнать это ?

КЛ>Ты путаешь предметную область заказчика с областью твоей компетенции, как программиста. Если ты не умеешь создавать сайты, то, следовательно, ты не являешься компетентным web-девелопером.

gandjustas взял такой пример, по нему и работаем.

КЛ>Кстати, критерий компетентности — это не знание определения понятия сайт, а именно умение разрабатывать сайты.

Ценное замечание, К.О. Как оно относится к нынешней беседе ?

I>>Ага, и с сайтом, и с редактором, а ты будешь в сторонке курить ?
КЛ>Пока что ты не привёл ни одного рабочего примера, иллюстрирующего твой подход. А как известно, практика — критерий истинности.

У меня нет никакого "моего" подхода. Есть подход который изложен в книге DDD Эрика Эванса.

Хочешь рабочий пример, смотри первоисточник — http://dddsample.sourceforge.net/

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

I>Хочешь рабочий пример, смотри первоисточник — http://dddsample.sourceforge.net/

Я все никак не соберусь с силами разобрать пример по кирпичикам и написать нормальное решение.

Если вкратце смотри там классы *Facade, это и есть функции, а куча неэффективного кода внутри — это DDD

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

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

I>>>Предположим, я ничего не знаю про сайты и тд.

I>>>Вопрос — что такое сайт про который ты говоришь ? У меня на бумаге уже строится модель — квадратик, с подписью "сайт ?" и стрелочка ведет пока в троеточие.

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

I>Я не понимаю что значит слово "сайт". Что это такое или где можно узнать это ?
Ну вот http://rsdn.ru это сайт, и http://gandjustas.blogspot.com тоже сайт. (я вот честно определения не знаю поэтому привожу примеры)

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

I>>>Зачем ? Это сделал Лебедев, только задом наперёд.
G>>Так сделай ты, как считаешь правильно.

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

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

G>Я все никак не соберусь с силами разобрать пример по кирпичикам и написать нормальное решение.

G>Если вкратце смотри там классы *Facade, это и есть функции, а куча неэффективного кода внутри — это DDD

Да, это не Linq2Entities Не знаю, на основании чего ты решил, что это неэффективный код.

По моему код очень понятный. Вот и Роберт Мартин пишет что качественный код имеет низкий показатель WTF/сек.

Как быть ?

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

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

G>>Я все никак не соберусь с силами разобрать пример по кирпичикам и написать нормальное решение.

G>>Если вкратце смотри там классы *Facade, это и есть функции, а куча неэффективного кода внутри — это DDD

I>Да, это не Linq2Entities Не знаю, на основании чего ты решил, что это неэффективный код.
Слишком много приседаний для выполнения довольно простых действий.
Использование aggregate root_ов заставляет тянуть больше данных, чем необходимо. Это сильно нарушает масштабируемость приложения.
Разделение на слои чисто формальное, по факту изменение в UI потянет изменения вплоть до БД.

I>По моему код очень понятный. Вот и Роберт Мартин пишет что качественный код имеет низкий показатель WTF/сек.
Понимание кода — умение которое можно тренировать. При некотором уровне умения можно понимать pointless запись на хаскеле.
Низкий показатель WTF\sec можно сделать разувая код тривиальными и ненужными вещами.
Зачастую DDD этим и занимается — перекладывает данные из одних объектов в другие это и создает видимость того что все понятно. Хотя если WFT\sec разделить на плотность функционала, то показатель будет вполне адекватным.

I>Как быть ?
Забить на DDD.
Есть более простые способы решения, в том числе сложных задач.

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

G>Использование aggregate root_ов заставляет тянуть больше данных, чем необходимо. Это сильно нарушает масштабируемость приложения.
G>Разделение на слои чисто формальное, по факту изменение в UI потянет изменения вплоть до БД.

Это набор слов.

I>>По моему код очень понятный. Вот и Роберт Мартин пишет что качественный код имеет низкий показатель WTF/сек.
G>Понимание кода — умение которое можно тренировать. При некотором уровне умения можно понимать pointless запись на хаскеле.

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

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

А если ты _любой_ код одинаково легко читатпешь, то про таких людей например Кент Бек с Фаулером пишут, что им не нужны ни книги по программированию ни методики

G>Низкий показатель WTF\sec можно сделать разувая код тривиальными и ненужными вещами.
G>Зачастую DDD этим и занимается — перекладывает данные из одних объектов в другие это и создает видимость того что все понятно.

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

>Хотя если WFT\sec разделить на плотность функционала, то показатель будет вполне адекватным.

Вот, ты уже понял, как считается WTF/сек

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

Я уже давно понял — взять КорелДро и слизать.

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

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

G>>Использование aggregate root_ов заставляет тянуть больше данных, чем необходимо. Это сильно нарушает масштабируемость приложения.
G>>Разделение на слои чисто формальное, по факту изменение в UI потянет изменения вплоть до БД.

I>Это набор слов.
Покажи как сделать настраиваемую сортировку в UI


I>>>По моему код очень понятный. Вот и Роберт Мартин пишет что качественный код имеет низкий показатель WTF/сек.
G>>Понимание кода — умение которое можно тренировать. При некотором уровне умения можно понимать pointless запись на хаскеле.

I>Открываешь один файл и читаешь — если все понятно, код стало быть хороший, для тебя разумеется.
I>Открываешь другой файл и читаешь — если есть сложности, стало быть код плохой.
Само по себе это ничего не значит. Гораздо важнее что делает код который ты читаешь. Если он не делает ничего нетривиального, то показатель WTF\sec ничего не изменит.

G>>Низкий показатель WTF\sec можно сделать разувая код тривиальными и ненужными вещами.
G>>Зачастую DDD этим и занимается — перекладывает данные из одних объектов в другие это и создает видимость того что все понятно.
I>То есть если я в твоей программе буду перекладывать данные из одних объектов в другие, то получится, что ты занимался ДДД ?
Логика офигеть. Я говорю A => B, ты говоришь B => A. Ботай матлогику, с формальными рассуждениями у тебя слабовато.

I>>>Как быть ?
G>>Забить на DDD.
G>>Есть более простые способы решения, в том числе сложных задач.
I>Я уже давно понял — взять КорелДро и слизать.
Ну если DDD не позволяет этого сделать, а другие методики позволяют, то зачем тогда нужен DDD?

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

G>>>Использование aggregate root_ов заставляет тянуть больше данных, чем необходимо. Это сильно нарушает масштабируемость приложения.
G>>>Разделение на слои чисто формальное, по факту изменение в UI потянет изменения вплоть до БД.

I>>Это набор слов.
G>Покажи как сделать настраиваемую сортировку в UI

Зачем мне чего то показывать если ты не можешь внятно объяснить проблемы кода ?

Ты уверен что код проектировался для твоих задач ?

I>>Открываешь один файл и читаешь — если все понятно, код стало быть хороший, для тебя разумеется.
I>>Открываешь другой файл и читаешь — если есть сложности, стало быть код плохой.
G>Само по себе это ничего не значит. Гораздо важнее что делает код который ты читаешь. Если он не делает ничего нетривиального, то показатель WTF\sec ничего не изменит.

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

G>>>Есть более простые способы решения, в том числе сложных задач.
I>>Я уже давно понял — взять КорелДро и слизать.
G>Ну если DDD не позволяет этого сделать, а другие методики позволяют, то зачем тогда нужен DDD?

КорелДро(сайта, программы) у тебя может и не быть.

Собственно Эванс и утверждает, что ДДД не является абсолютной методикой.

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

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

G>>>>Использование aggregate root_ов заставляет тянуть больше данных, чем необходимо. Это сильно нарушает масштабируемость приложения.
G>>>>Разделение на слои чисто формальное, по факту изменение в UI потянет изменения вплоть до БД.

I>>>Это набор слов.
G>>Покажи как сделать настраиваемую сортировку в UI

I>Зачем мне чего то показывать если ты не можешь внятно объяснить проблемы кода ?
Я-то могу, но ты не поверишь.
Поэтому просто попробуй добавить настраиваемую сортировку в интерфейс.
Тебе придется добавить её в
1)Фасад
2)Репозиторий
3)Сервисы (в некоторых случаях)
4)Поменять спецификации и их генерацию (тоже в некоторых случаях)

Причем последний пункт самый критичный.

С Linq (или любым другим QueryObject), без такой уродской модели репозитариев и растягивания логики по разным объектам, я смогу в прямо в PL написать
query.OrderBy(predicate)

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

I>>>Открываешь один файл и читаешь — если все понятно, код стало быть хороший, для тебя разумеется.
I>>>Открываешь другой файл и читаешь — если есть сложности, стало быть код плохой.
G>>Само по себе это ничего не значит. Гораздо важнее что делает код который ты читаешь. Если он не делает ничего нетривиального, то показатель WTF\sec ничего не изменит.

I>Конечно же значит. И для тривиального, и для нетривиального. Проявляется это во времени, которое тебе придется потратить, что бы понять и гарантировать например безотказную работу.
Зачем тратить время чтобы гарантировать "безотказную работу" того что можно выкинуть?
А немалая часть примеров про DDD именно такая.

G>>>>Есть более простые способы решения, в том числе сложных задач.
I>>>Я уже давно понял — взять КорелДро и слизать.
G>>Ну если DDD не позволяет этого сделать, а другие методики позволяют, то зачем тогда нужен DDD?

I>КорелДро(сайта, программы) у тебя может и не быть.

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

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

I>>Зачем мне чего то показывать если ты не можешь внятно объяснить проблемы кода ?
G>Я-то могу, но ты не поверишь.

Конечно, один ты работаешь

G>Поэтому просто попробуй добавить настраиваемую сортировку в интерфейс.

Не нужно валять дурака. Объясни внятно или вообще ничего не говори.

G>С Linq (или любым другим QueryObject), без такой уродской модели репозитариев и растягивания логики по разным объектам, я смогу в прямо в PL написать
G>query.OrderBy(predicate)

А без Linq ?

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

Опаньки, уже задачи стали неважны. Вижу, ты в ударе. Чую, скоро будешь отрицать отрицание важности задач

G>Иначе это хреновый дизайн, как бы "красиво" он не выглядел.

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

Хорошую идею ты мне подал — пойду составлять список того, чего меня не просили да выбью года три под это дело

I>>Конечно же значит. И для тривиального, и для нетривиального. Проявляется это во времени, которое тебе придется потратить, что бы понять и гарантировать например безотказную работу.
G>Зачем тратить время чтобы гарантировать "безотказную работу" того что можно выкинуть?

А как ты узнаешь, что это можно выкинуть до того, как поймешь что это надо выкинуть ?

Вот этот зазор и определяется чз WTF/сек.

G>Давайте определим где же он хорош. Вот из его книги DDD (да и вообще ООП) хорошо работает на задаче моделирования. Именно такую задачу он рассматривает на протяжении первых глав.

G>Но ярые функциональщики тебе покажут что моделирование также неплохо делается на ФЯ, особенно моделирование формальных систем, типа микросхем.

А он микросхемы не моделирует. Ты снова чего то вычитал своего.

G>Для всех остальных задач применимость DDD (как методики проектирования, так и конкретных паттернов) остается под вопросом.

У меня с каждым твоим собщением все больше сомнений в том, что ты читал книгу

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

G>>С Linq (или любым другим QueryObject), без такой уродской модели репозитариев и растягивания логики по разным объектам, я смогу в прямо в PL написать
G>>query.OrderBy(predicate)

I>А без Linq ?
Выделенное читай. Criteria для Hibernate.
Да и какой смысл сейчас без Linq писать?

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

I>Опаньки, уже задачи стали неважны. Вижу, ты в ударе. Чую, скоро будешь отрицать отрицание важности задач
Не съезжай. Тут мы уже говорим о результате, а не о процессе.
Следи за нитью разговора и не цепляйся к словам.

G>>Иначе это хреновый дизайн, как бы "красиво" он не выглядел.
I>Я понял — задачи не важны, главное что бы сортировки, расширение, изменение было даже в том случае, если никто тебя об этом не просил.
Пример с сортировкой самый простой и показательнный.
Если что 90% работы любого enterprise приложения это отображение данных. Если тебе на каждую правку отображения придется менять код во всех слоях, то это плохо.
Будешь ты этим заниматься или нет — твоя проблема.


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

G>>Давайте определим где же он хорош. Вот из его книги DDD (да и вообще ООП) хорошо работает на задаче моделирования. Именно такую задачу он рассматривает на протяжении первых глав.
G>>Но ярые функциональщики тебе покажут что моделирование также неплохо делается на ФЯ, особенно моделирование формальных систем, типа микросхем.
I>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
А чем же?

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

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

Пример из жизни
Однажды меня попросили автоматизировать одну задачу, для решения которой использовался Excel. Посмотрев на этот Excel, я понял что задача чисто для БД, сделал простенькую БД на Access и прикрутил к ней ГУИ. Так вот пользователи на меня потом смотрели как на великого гуру, познавшего основы мироздания, просто увидев два грида мастер-детейл. Т.е. они даже не представляли что такое возможно.

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

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

I>>Опаньки, уже задачи стали неважны. Вижу, ты в ударе. Чую, скоро будешь отрицать отрицание важности задач
G>Не съезжай. Тут мы уже говорим о результате, а не о процессе.

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

G>>>Иначе это хреновый дизайн, как бы "красиво" он не выглядел.
I>>Я понял — задачи не важны, главное что бы сортировки, расширение, изменение было даже в том случае, если никто тебя об этом не просил.
G>Пример с сортировкой самый простой и показательнный.
G>Если что 90% работы любого enterprise приложения это отображение данных. Если тебе на каждую правку отображения придется менять код во всех слоях, то это плохо.

Это общие слова. Был конкретный пример с неэффективным кодом, а стало "90% работы любого"

I>>Вот этот зазор и определяется чз WTF/сек.
G>Ну в этом и разница, можно тратить эти sec, на то чтобы понять что код не нужен, а можно их тратить на что-либо более полезное.

И там тоже будет WTF/сек Но я уже понял главную мысль — знание о том, что можно выкинуть,а что оставить, дадено свыше и на это не надо тратить время.

G>>>Но ярые функциональщики тебе покажут что моделирование также неплохо делается на ФЯ, особенно моделирование формальных систем, типа микросхем.
I>>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>А чем же?

Тебе должно быть виднее чем же ты вычитал.

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

И по этому я тебе минима пять раз приводил цитаты ?

Вобщем сдается беседа себя исчерпала.

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

G>>>>Иначе это хреновый дизайн, как бы "красиво" он не выглядел.
I>>>Я понял — задачи не важны, главное что бы сортировки, расширение, изменение было даже в том случае, если никто тебя об этом не просил.
G>>Пример с сортировкой самый простой и показательнный.
G>>Если что 90% работы любого enterprise приложения это отображение данных. Если тебе на каждую правку отображения придется менять код во всех слоях, то это плохо.

I>Это общие слова. Был конкретный пример с неэффективным кодом, а стало "90% работы любого"
Это статистика, которую глупо отрицать.

I>>>Вот этот зазор и определяется чз WTF/сек.
G>>Ну в этом и разница, можно тратить эти sec, на то чтобы понять что код не нужен, а можно их тратить на что-либо более полезное.

I>И там тоже будет WTF/сек Но я уже понял главную мысль — знание о том, что можно выкинуть,а что оставить, дадено свыше и на это не надо тратить время.
Нет. Ситуация простая.
Ты читаешь тыщу строк кода с показателем WTF\min = 1. Ты тратишь на это около 10 минут, получаешь 10 WTFов.
Потом понимаешь что тоже самое реально сделать кодом в 100 строк, в показателем WTF\min = 3. Затратив на чтение такого кода 3 минуты и получаешь 9 WTF.
В итоге и мозг целее, и времени уйдет меньше.

G>>>>Но ярые функциональщики тебе покажут что моделирование также неплохо делается на ФЯ, особенно моделирование формальных систем, типа микросхем.
I>>>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>>А чем же?
I>Тебе должно быть виднее чем же ты вычитал.
Ты уходишь от ответа.

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

I>>Это общие слова. Был конкретный пример с неэффективным кодом, а стало "90% работы любого"
G>Это статистика, которую глупо отрицать.

Из этого никак не следует, что код неэффективный. Кроме того, не ясно, как ты определил эффективность.

I>>И там тоже будет WTF/сек Но я уже понял главную мысль — знание о том, что можно выкинуть,а что оставить, дадено свыше и на это не надо тратить время.
G>Нет. Ситуация простая.
G>Ты читаешь тыщу строк кода с показателем WTF\min = 1. Ты тратишь на это около 10 минут, получаешь 10 WTFов.
G>Потом понимаешь что тоже самое реально сделать кодом в 100 строк, в показателем WTF\min = 3. Затратив на чтение такого кода 3 минуты и получаешь 9 WTF.
G>В итоге и мозг целее, и времени уйдет меньше.

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

Но даже с твоими взятыми с потолка цифрами не все в порядке — в итоге у тебя будет 19 WTF а не 9

Хотя если предположить, что абсолютное знание дадено свыше, то действительно 9 получается

I>>>>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>>>А чем же?
I>>Тебе должно быть виднее чем же ты вычитал.
G>Ты уходишь от ответа.

Где именно ? В примере про Cost Based Mesh Design ты завял. С сайтом, твой же пример, завял. С "неэффективным кодом" дошел до статистики.
Для примера с WTF/сек взял цифры с потолка и все равно ошибся

После всего этого не вижу никакого смысла в продолжении беседы

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

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

I>>>Это общие слова. Был конкретный пример с неэффективным кодом, а стало "90% работы любого"
G>>Это статистика, которую глупо отрицать.

I>Из этого никак не следует, что код неэффективный.
Во-первых слишком много кода для простых вещей. Причем тривиального кода.

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

I>>>И там тоже будет WTF/сек Но я уже понял главную мысль — знание о том, что можно выкинуть,а что оставить, дадено свыше и на это не надо тратить время.
G>>Нет. Ситуация простая.
G>>Ты читаешь тыщу строк кода с показателем WTF\min = 1. Ты тратишь на это около 10 минут, получаешь 10 WTFов.
G>>Потом понимаешь что тоже самое реально сделать кодом в 100 строк, в показателем WTF\min = 3. Затратив на чтение такого кода 3 минуты и получаешь 9 WTF.
G>>В итоге и мозг целее, и времени уйдет меньше.

I>Это в учебнике по матлогике написано, что надо брать цифры с потолка для доказательства ?
Это не доказательство, это иллюстрация того что WTF\sec не говорит хорошести кода.

I>>>>>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>>>>А чем же?
I>>>Тебе должно быть виднее чем же ты вычитал.
G>>Ты уходишь от ответа.

I>Где именно ?
Я спросил разработкой какого приложения занимается эванс в книге, в начале. Ты не ответил.

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

I>>Из этого никак не следует, что код неэффективный.
G>Во-первых слишком много кода для простых вещей. Причем тривиального кода.

I>>Кроме того, не ясно, как ты определил эффективность.

G>Количество трудозатрат на реализацию и поддержку.

Вот так матлогика — максимальная эффективность — минимум трудозатрат

Получается отсутствие сайта будет максимально эффективным результатом Отсюда, кстати, и "Эффективные менеджеры" — они тоже считают что эффективность это трудозатраты.

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

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

В соседнем форуме этот тезис но немного в другой форме оспаривает Pavel Dvorkin

I>>Это в учебнике по матлогике написано, что надо брать цифры с потолка для доказательства ?
G>Это не доказательство, это иллюстрация того что WTF\sec не говорит хорошести кода.

Интересно, как цифры с потолка да еще с ошибкой в подаче материала, могут иллюстрировать чего-либо ?

I>>Где именно ?
G>Я спросил разработкой какого приложения занимается эванс в книге, в начале. Ты не ответил.

I>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>А чем же?

Ты это имел ввиду ?

У Эванса софт был для проектирования печатных плат, а не для моделирования микросхем. Более того, прямо написано, что микросхемы они не моделировали и не должны были этого делать

Да и ежу понятно, моделирование микросхем(микроэлектроника) и проектирование печатных плат это мягко говоря разные области

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

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

I>>>Из этого никак не следует, что код неэффективный.
G>>Во-первых слишком много кода для простых вещей. Причем тривиального кода.

I>>>Кроме того, не ясно, как ты определил эффективность.

G>>Количество трудозатрат на реализацию и поддержку.

I>Вот так матлогика — максимальная эффективность — минимум трудозатрат
Ты как-то про функционал забыл в этой формуле.

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

I>В соседнем форуме этот тезис но немного в другой форме оспаривает Pavel Dvorkin


I>>>Это в учебнике по матлогике написано, что надо брать цифры с потолка для доказательства ?
G>>Это не доказательство, это иллюстрация того что WTF\sec не говорит хорошести кода.
I>Интересно, как цифры с потолка да еще с ошибкой в подаче материала, могут иллюстрировать чего-либо ?
Так и так и могут.
Но ты бы лучше суть понял что метрики первого порядка ничего не говорят о коде.
Поэтому твоя логическая цепочка что "код хороший, потому что понятный, потому что WTF\sec низкий" неверна.

I>>>Где именно ?
G>>Я спросил разработкой какого приложения занимается эванс в книге, в начале. Ты не ответил.

I>

I>>А он микросхемы не моделирует. Ты снова чего то вычитал своего.
G>>А чем же?

I>Ты это имел ввиду ?
I>У Эванса софт был для проектирования печатных плат, а не для моделирования микросхем. Более того, прямо написано, что микросхемы они не моделировали и не должны были этого делать
I>Да и ежу понятно, моделирование микросхем(микроэлектроника) и проектирование печатных плат это мягко говоря разные области
Ты опять уперся в терминологию, вместо сути.

Developer: I understand how the signal gets carried by the Net to all
the Pins attached, but how does it go any further than that?
Does the Topology have something to do with it?
Expert 2: No. The component pushes the signal through.
Developer: We certainly can’t model the internal behavior of a chip.
That’s way too complicated.
Expert 2: We don’t have to. We can use a simplification. Just a list of
pushes through the component from certain Pins to certain others.

То есть таки моделируют наблюдаемое поведение микросхем, хотя не только микросхем.

Опять-таки возвращаясь к нашим баранам.

I>Да и ежу понятно, моделирование микросхем(микроэлектроника) и проектирование печатных плат это мягко говоря разные области
Может и разные, но эванс показал одну задачу — распространение сигнала в цепи, которая будет решаться одинаково и для печатных плат и для микросхем. Потому что там важна принципиальна схема, а не на каком материале она выполнена.

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

G>>>Количество трудозатрат на реализацию и поддержку.

I>>Вот так матлогика — максимальная эффективность — минимум трудозатрат
G>Ты как-то про функционал забыл в этой формуле.

Ну так это твоя формула. "Количество трудозатрат на реализацию и поддержку"

Где здесь функционал — не ясно.

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

"Количество трудозатрат на реализацию и поддержку"

I>>Интересно, как цифры с потолка да еще с ошибкой в подаче материала, могут иллюстрировать чего-либо ?
G>Так и так и могут.
G>Но ты бы лучше суть понял что метрики первого порядка ничего не говорят о коде.
G>Поэтому твоя логическая цепочка что "код хороший, потому что понятный, потому что WTF\sec низкий" неверна.

Чудеса матлогики понятный == WTF\sec низкий. Хороший потому что понятный.

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

Про эффективность кода, программы ты вообще ничего не смог сказать.

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

G>То есть таки моделируют наблюдаемое поведение микросхем, хотя не только микросхем.

Ты заменил " моделирование микросхем" на "моделируют наблюдаемое поведение микросхем"

Ты понимаешь, что это не одно и то же ?

I>>Да и ежу понятно, моделирование микросхем(микроэлектроника) и проектирование печатных плат это мягко говоря разные области
G>Может и разные, но эванс показал одну задачу — распространение сигнала в цепи, которая будет решаться одинаково и для печатных плат и для микросхем. Потому что там важна принципиальна схема, а не на каком материале она выполнена.

Решается она для _печатной_ платы. Для микросхемы все будет сложнее, и эти детали уже не учитываются.

Продолжение цикла статей по проектированию графического редактора:

Привычные нам графические редакторы для настольных ПК предоставляют пользователю множество готовых примитивов. Например, графический редактор, встроенный в Microsoft Word 2003, содержит 115 готовых автофигур.
Взаимодействие с пользователем в таких редакторах можно описать при помощи следующего юз-кейса:

1. Программа предоставляет набор готовых фигур.
2. Пользователь выбирает фигуру из набора.
3. Пользователь задает расположение и размеры фигуры.
4. Программа рисует фигуру в указанном месте и заданного размера.

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

Дальше >>

Еще одна статья о проектировании интерфейса:

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

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

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

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

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

Дальше »