На чем пишется софт для КА?

[jettero]

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

Это не мешает имплементировать DDD.

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

Ну раз вам и правда интересно насчет вопросов формализма модели, в онлайне есть вот такой труд http://www.4shared.com/file/110803289/43537f8c/DomainDrivenDesignQuicklyOnline.html , это можно считать кратким пересказом книжки Иванса.

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

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

[Not]

Ну раз вам и правда интересно насчет вопросов формализма модели, в онлайне есть вот такой труд http://www.4shared.com/file/110803289/43537f8c/DomainDrivenDesignQuicklyOnline.html , это можно считать кратким пересказом книжки Иванса.

посмотрел по диагонали. Почитал внимательно главау про "вездесущий" язык (ну и название блин!) И... ничего не понял. Т.е. вообще ничего. Там нет языка. Там есть алфавит языка, определенный набором сущностей (entities). Но язык еще предполагает грамматику. Об этом, однако, ни слова.

Цитаты из главы Ubiquitous Language

"What should we use for the language? Just speech? We've used diagrams."

"So UML cannot convey two important aspects of a model: the meaning of the concepts it represents and what the objects are supposed to do. But that is OK, since we can add other communication tools to do it."

"We can use documents. One advisable way of communicating the model is to make some small diagrams each containing a subset of the model. These diagrams would contain several classes, and the relationship between them. That already includes a good portion of the concepts involved. Then we can add text to the diagram. The text will explain behavior and constraints which the diagram cannot. Each such subsection
attempts to explain one important aspect of the domain, it points a "spotlight" to enlighten one part of the domain. Those documents can be even hand-drawn, because that transmits the feeling that they are temporary, and might be changed in the near future, which is true, because the model is changed many times in the beginning before it reaches a more stable status."

"It is also possible to communicate using code."

"There are other ways to communicate during design. It's not the
purpose of this book to present all of them."

Вы не поясните, о чем вообще речь? Сначала справедливао критикуется UML. Потом он же используется в последующих главах в качестве языка. Далее уточняется, что можно и другие языки использовать, вплоть до записок на манжетах. Это что ли и есть ваш Вездесущий Язык?

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

Я не понял, вы сами-то этим пользовались? Как интересно вы собрались объединять "две успешные старые практики", если они друг с другом несовместны и совместными быть не предполагались? Из прочтения этого документа я не вынес вообще ничего. Когда мне пишут - рисуйте UML диаграммы, если этого мало - пишите свободным текстом, если и этого мало - есть другие средства но мы вам не расскажем, ибо книжка не про то. А простите, про что эта книжка?  :shock:

[jettero]

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

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

Насчет практики я сейчас пользуюсь фреймворком FLOW3, который позволяет реализовать почти все концепции DDD "из коробки", но он еще в alfa release.

[Not]

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

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

Вы меня простите, но я со своим традиционным образованием в нее вникнуть не смогу. Ибо для меня термин "язык" имеет вполне определенный смысл. Если автор книжки этот термин переопределяет или извращает, дальнейшее чтение интереса не вызывает   А уж "вездесущий" язык... Чур меня, чур! Касательно же книжки - а вы можете сказать навскидку, чем DDD отличается от RUP (Rational Unified Process)?

[jettero]

Ну как хотите, вас никто не заставляет
RUP это от IBM? навскиддку сказать не могу, не работал с ним.

[Not]

Ну как хотите, вас никто не заставляет
RUP это от IBM? навскиддку сказать не могу, не работал с ним.

А, ну тогда мне становится понятным ваш энтузизм RUP - это от компании Rational, которую впоследствии купила IBM. Берет свое начало от трудов Буча, Румбау и Йенсена, из работ которых собственно и был создан UML. Впоследствии они создали компанию Rational, сформулировали итеративный жизненный цикл программных продуктов и выпустили продукт Rational Rose - оболочку для отрисовки моделей и кодогенерации. Но там были хорошие формализмы. Глядя на DDD можно в разных местах увидеть торчащие уши RUP, хотя авторы старательно увиливают от упоминания оного  :wink:

[jettero]

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

Кстати обратный пример, нагуглил уши DDD в статье в разделе Rational (это же отцы RUP'а?) на сайте IBM  
http://www.ibm.com/developerworks/library/ar-apparch2/index.html

Domain model

Domain modeling isn't really new, but little has been published on just how to do it. Eric Evans' book Domain-Driven Design (see Resources) provides a set of patterns for modeling domains that includes techniques for identifying and factoring domain boundaries and refining the domain designs.

Using these techniques to document your domain will go a long way toward giving your application architectures a long and happy life.

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

[jettero]

А вообще словосочетание "domain-driven design" на сайте IBM встречается 54 раза
http://www.google.ru/search?hl=ru&newwindow=1&q=%22domain-driven+design%22+site%3Aibm.com&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=

А "Eric Evans" 44 раза    
http://www.google.ru/search?hl=ru&newwindow=1&q=%22Eric+Evans%22+site%3Aibm.com&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=

[Not]

А вообще словосочетание "domain-driven design" на сайте IBM встречается 54 раза
http://www.google.ru/search?hl=ru&newwindow=1&q=%22domain-driven+design%22+site%3Aibm.com&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=

А "Eric Evans" 44 раза    
http://www.google.ru/search?hl=ru&newwindow=1&q=%22Eric+Evans%22+site%3Aibm.com&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=

А Гради Буч 22000 раз. Ну и что из того?

http://www.google.ru/search?hl=ru&newwindow=1&q=%22Grady+Booch%22+site%3Aibm.com&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=

[jettero]

Ничего удивительного - Гради Буч & UML как бы это родная тема для IBM, а DDD к IBM никаким боком не относится. И DDD относительно недавно появилось, поэтому ссылок пока еще мало, но они есть, значит технология используется.
В общем факт, что топовые IT архитекторы пишут, что это нужная технология (даже разработчики под ваш RUP) и стараются ее продвигать в массы (тот же главред infoQ), мой пока небольшой опыт c DDD, говорит мне, что это полезная вещь.
Изучать это или нет ваша дело, думаю можно дальше это не обсуждать

[TAU]

PS

Скажем, вы слышали о машинах, управляемых потоками данных?

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

Прошу прощения. И почитать можно?

[TAU]

Уважаемый Not!

Почитал внимательно главу про "вездесущий" язык (ну и название блин!) И... ничего не понял. Т.е. вообще ничего. Там нет языка... простите, про что эта книжка?  :shock:

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

Так что надеяться на

было бы значительно интереснее, если бы он
1. Определил формализм, на котором базируются его модели.
2. Показал бы, насколько его формализм эффективнее других в смысле сокращения пространства состояний программы (системы), необходимых для постижения программистом.
3. Привел бы вычислительно доступные формальные способы анализа (верификации) программ в рамках этого формализма.
Если бы он в этом процессе развил например идеи Ковальски, или Дейкстры или Петри, или Нариньяни, или Хоара и т.д. и т.п, то и честь ему и хвала.  Я уж не говорю о создании нового конструктивного формализма

думаю, совершенно не стоит.

Зато:  

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

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

Буду счастлив, если я ошибаюсь.

[Not]

Уважаемый Not!
Зато:  

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

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

Буду счастлив, если я ошибаюсь.

Ну это совершенно нормальная ситуация. "Энтерпрайз девелоперы" образовались в больших количествах во время Интернет-бума, произошедшего в конце прошлого века, когда оказалось, что, благодаря  появлению многофункциональный контейнеров приложений, можно обладая относительно небольшим запасом знаний можно строить большие и сложные системы масштаба предприятия, не уделяя большого внимания таким традиционным проблемам как синхронизации процессов, распределению памяти и т.д.  Естественно, что создание больших проектов в контейнерах приложений требует определенной практики, знания интерфейсов и умение организовать свою работу. Именно в целях эффективной организации появлись многочисленные практические наработки, такие как UML (язык моделирования объектных систем), Design Patterns (набор практически полезных шаблонов проектирования), многочисленных оболочек с разной функциональностью (Spring, разнообразные MVC-решения, Hibernate и многие другие). Очевидно, что авторы этих оболочек пишут книги (хороший способ "монетизации" опыта). Как правило эти книги пишутся крупным шрифтом, с большим количеством картинок, вольных отступлений, нестрогими а часто вообще алогичными выводами, абсолютно "отфонарной" терминологией и так далее. Иногда эти практики называют себя "отцами" в той или иной области "энтерпрайз девелопмента", любят собирать семинары, проводить конференции по обмену опытом

В большом количестве "энтерпрайз девелоперы" появились в Индии, где в университетах принят прагматичный подход к образованию, в отличии от фундаментального в СССР/России.  При таком прагматичном подходе учат конкретным вещам, например программированию на С++ или Java, в среде .NET или J2EE. Фундаментальные же курсы, такие как линейная алгебра, дискретная математика, физика, анализ алгоритмов, теория сложности, распределенные и параллельные алгоритмы  и т.д.,  даются в минимальном объеме, часто ознакомительном. Как следствие - выходят сильные но очень узкие специалисты, неспособные решить проблему за рамками уютного теплого контейнера. Собственно об этой узости образования мне говорили сами индийские программисты.

Очевидно, что и в России появились многочисленные последователи "ентерпрайз девелопмента", быстро почувствовавшие вкус легких побед при работе в рамках контейнеров, но слабо при этом разбирающихся в фундаментальных вещах. Это может быть оправдано в определенной узкой области "энтерпрайз девелопмента", но абсолютно нежизнеспособно при создании и сопровождении ответственных (mission critical) приложений. Собственно в США к этой области "энтерпрайз девелоперов" даже близко не подпускают. Образование, умение создавать мат. модели, алгоритмировать и верифицировать алгоритмы проверяются в первую очередь.

[TAU]

Ну это совершенно нормальная ситуация

Не согласен, что нормальная. Впрочем, тут может быть дело в тонкостях толкования понятия "нормальности". Объяснимая - да. Правильная? Нет!

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

Ага, я об этом и писал. Еще новые громкие термины придумывают.
Каждый год почти о "революции" объявляют.

прагматичный подход к образованию, в отличии от фундаментального в СССР/России.  При таком прагматичном подходе учат конкретным вещам, например программированию на С++ или Java, в среде .NET или J2EE

Это называется - ПТУ. Да, рабочие тоже нужны. Однако, все-таки не хотелось бы, чтобы наше университетское образование до такого деградировало. И программирование в целом - тоже. А процесс, к сожалению, идет  

[yos]

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

[Not]

Это называется - ПТУ.

Ну да, бакалавриат   Хотя я думал, что бакалавр - это хотя бы техникум.

[Александр Куприянов]

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

Техникумы (хреновые) есть, ПТУ - эквиваленты - тоже. В смысле - деградация образования - идет системно. Внесистемно - студенты-прагматики "доворачивают".
Они ж нормальные:)

[TAU]

Это называется - ПТУ.

Ну да, бакалавриат   Хотя я думал, что бакалавр - это хотя бы техникум.

Ну, по сроку обучения ближе к техникуму. Но хрень редьки не особо слаще - все равно образование среднее. Там "среднее профессиональное", тут - "среднее техническое".

[yos]

Бакалавры бывают разные, хотя наверное зависит от страны. В моём случае, я знаком с двумя. Bachelor of Technology -- 4 года обучения в учебном заведении сравнимом с советским институтом. А есть Bachelor of Science -- 3-4 года в настоящем университете. После этого большинство студентов продолжают учёбу, становясь Master of Science.
Так что, бакалавриат никак с "ПТУ" не связан и не может быть связан. И не среднее это образование. Этот термин и звание вообще происходит из "классических" университетов Европы и ему уже несколько сотен лет.

[TAU]

Бакалавры бывают разные, хотя наверное зависит от страны. В моём случае, я знаком с двумя. Bachelor of Technology -- 4 года обучения в учебном заведении сравнимом с советским институтом. А есть Bachelor of Science -- 3-4 года в настоящем университете. После этого большинство студентов продолжают учёбу, становясь Master of Science.
Так что, бакалавриат никак с "ПТУ" не связан и не может быть связан. И не среднее это образование. Этот термин и звание вообще происходит из "классических" университетов Европы и ему уже несколько сотен лет

А если подумать? Содержательно, а не формально?