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

[TAU]

если сменить подход к операторам языка программирования? Сделать из них подобие веб-узлов или операционных систем. Сейчас "операция" выполняется принудительно и фиксировано. В ОС она будет интелектуальной: сравнение с конфигурационным файлом, проверка на входе, анализ полученного результата, выдача в служебный канал сообщ. о ошибках и статистике, и т.д.  И уже из однообразных ОС собирать куски программ.  Эти куски будут уметь еще меньше, чем старый DOS, но иметь интерфейс для переговоров с программой на уровне школьника младших классов. Далее установка нескольких ОС на доске общей ОС

Вы не одиноки  :wink:
Подобные идеи развивают, в частности, в Техасском университете.

[TAU]

Гм... Судя по всему вы перевели с английского слова Domain-Driven Design и уже решили, что знаете о чем идет речь

ошибочное заключение.

DDD не имеет отношения к проблемно-ориентированным языкам

вот прямо-таки и не имеет? ;-) никакого отношения?
в целом - ошибочное высказывание.

Для применения парадигмы DDD достаточно любого ООП языка

И что?

В DDD включены некоторые старые вещи

Т.е. я прав.

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

jettero, я же вам написал - эх, молодо-зелено.

Ваше "новое" - это достаточно хорошо преданное забвению молодым поколением, самонадеянным и немного агрессивным  :wink:, всё на свете считающим "новым", старое.
Так что призывы "учить матчасть" лучше начните адресовать с себя.

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

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

Так что по сути - в новую "упаковку" засунули то, что, как я выше писал, естественно, давно применялось, в особенности - в создании БПО в авиации и космонавтике.

[jettero]

DDD не имеет отношения к проблемно-ориентированным языкам

вот прямо-таки и не имеет? ;-) никакого отношения?
в целом - ошибочное высказывание.

Ошибаетесь – к проблемно-ориентированным языкам программирования DDD не относится и проблемно-ориентированные языки для DDD не требуются. Эти подходы перпендикулярны друг к другу. Этот ваш перл про языки сразу и показал насколько вы в теме. То что вы выделили "выработка языка предметной области" тут говорится не про язык программирования, как вы почему-то решили. И "HAL/S, ПРОЛ, ПРОЛ2, СИПРОЛ, ГРАФИТ/ФЛОКС, и т.д., и т.п." к парадигме DDD отношения не имеют. Я же говорю – учите матчасть

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

jettero, я же вам написал - эх, молодо-зелено.

Ваше "новое" - это достаточно хорошо преданное забвению молодым поколением, самонадеянным и немного агрессивным  :wink:, всё на свете считающим "новым", старое.
Так что призывы "учить матчасть" лучше начните адресовать с себя.

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

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

Так что по сути - в новую "упаковку" засунули то, что, как я выше писал, естественно, давно применялось, в особенности - в создании БПО в авиации и космонавтике.

Вы мне ответьте на один вопрос – вы книгу читали? Или вы судите по DDD на основе Википедии? Так могу вас обрадовать, по Википедии я и сам думал, что это просто маркетинговый термин, а не технология. Причем это технология построения архитектуры, и что там использется некоторые старые вещи не удивительно, потому что она относится не к уровню языка, а к архитектуре ПО. Конечно, если упереться, то можно говорить, что все после Тьюринга и Фон-Неймана, это все тоже самое и сводится к машинным кодам в памяти, стеку и регистрам и ничего нового не придумали. Такой подход хорошое оправдание, чтобы не изучать новых технологий, – "я уже все знаю и ничего нового не придумают, это все обертка для старого"
Технологии не стоят на месте и то что вы их не изучаете под предлогом, что это уже было, это ваше личное дело – можете не изучать, от вас этого никто не требует. Для разработчиков же, особенно для разработчиков сложных систем, DDD сейчас это обязательная концепция для изучения и применения. Ну да, по-вашему они конечно же зеленые дураки, плохо учились в университетах и не понимают, что тут ничего нового нет
В целом ваша позиция довольно не профессиональна – "не изучал, но осуждаю".

PS Ах да, еще вы все на мой зеленый возраст намекаете. Универ я закончил 11 лет назад. В универе я работал на кафедре в лаборатории, которая одновременно была АОЗТ с лицензией министерства обороны и занималась разработкой бортовых компов для танков и ЗРК. Разработка компа для Тунгуски, например, делалась в той же лаборатории и за нее универу дали орден Трудового Красного Знамени в советское время. Также у меня есть научные публикации на тему не Фон-Неймановской архитектуры, а конкретнее на тему машины управляемой потоком данных (это связано с тематикой, по которой я работал в лаборатории). Мой одногруппник, который работал там же, занимался портированием RTEMS на железку для одной из ЗРК и регулярно ездил на стрельбы итп.
Так что я хорошо представляю совковый подход к программированию, на который вы здесь ссылаетесь и могу судить, что новое, а что нет  

[TAU]

jettero, умерьте агрессию. Просто неприятно с вами общаться из-за этого, честно говоря.  :? Вместо того, чтобы сломя голову с шашкой наголо в бой бросаться, вы бы более вдумчиво читали то, что вам пишут.

Ошибаетесь – к проблемно-ориентированным языкам DDD не относится и проблемно-ориентированные языки для DDD не требуются. Эти подходы перпендикулярны друг к другу. Этот ваш перл про языки сразу и показал насколько вы в теме

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

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

Вы мне ответьте на один вопрос – вы книгу читали? Или вы судите по DDD на основе Википедии?

Вышеприведенные цитаты - они, по-вашему, из википедии?

это технология построения архитектуры, и что там использется некоторые старые вещи не удивительно, потому что она относится не к уровню языка, а к архитектуре ПО. Конечно, если упереться, то можно говорить, что все после Тьюринга и Фон-Неймана, это все тоже самое и сводится к машинным кодам

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

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

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

"я уже все знаю и ничего нового не придумают

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

то что вы их не изучаете под предлогом, что это уже было, это ваше личное дело

То, что я "не изучаю" - это ваши личные (ложные) домыслы.

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

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

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

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

В целом ваша позиция довольно не профессиональна – "не изучал, но осуждаю"

Где я осуждаю? Что вы тут городите какие-то надуманные обвинения?
Проблемно-ориентированный подход не только не считаю плохим, но, напротив, активно использую и сам. Только вот я не считаю, что это понятие надо ограничивать узкими рамками того, что вы называете Domain-Driven Design.

[jettero]

Вы не ответили на мой вопрос – вы книгу (Evans, E., Domain-Driven Design - Tackling Complexity in the Heart of Software, 2004, Addison-Wesley) читали?

А насчет агресии – так это вы начали нападать на меня, а не я. Я лишь посоветовал обратить внимание на новую технологию DDD, потому что она реально помогает в разработке и содержит конкретные архитектурные решения.
Это у вас вызвало целый поток критики, что я зеленый, не понимаю, что это такое итп. А на деле я вижу, что вы даже не разбирались в том, о чем спорите. Я вот уверен, что вы не работали ни с AOP, ни с ORM, ни с Persistence framework, не так ли? Потому что этого всего нету в тех языках которые вы перечисляли. Но это все часть архитектуры, которая продвигается в DDD. Это и дает мне повод сомневаться в том, что вы знаете о чем спорите. Те общие фразы про DDD, что вы писали, это из какой-то общей статьи про DDD, не из книги.

[jettero]

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

Однако DDD – это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо учитывать, если вы решили следовать DDD, таких как: фокусирование на высокий приоритет отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д...это является  основной причиной ознакомиться с книгой Эрика Ивенса, так как она даст вам более объемное и глубокое понимание философии DDD.

Как видите и здесь вам советуют прочесть наконец книгу Эрика Ивенса  

[jettero]

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

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

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

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

[Not]

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

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

[Not]

Я персонально писал ОС РВ, готов ответить на вопросы.

А что именно Вы называете ОС РВ? Диспетчер прикладных задач? Управление "железом"?

ОС РВ = операционная система реального времени. Та, что писал я представляла из себя многозадачную ОС с вытеснением и приоритетностью задач/прерываний. Включала в себя диспетчер задач/прерываний, управление внешней памятью (процессор - специальное расширение Intel 286), драйверы PCMCIA, граф. адаптера  последовательного порта, сенсорного экрана, GPS-приемника (одного из первых), управление питанием и кое-что еще по мелочи. Библиотеки поддержки многозадачности (семафоры, очереди, мониторы и т.д.), работы с графическими функциями и т.п. Все писалось под конкретную задачу, с минимумом дополнительной функциональности. Писалось потому, что существующие компактные ОС РВ или не подходили к этому железу, или банально не влезали в память. После консультаций с разработчиками оных (в частности Apple и Gео Works) было решено плюнуть на это безобразие и рискнуть сделать самим.

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

Портировалось туда специальное ПО написанное для ОС VRTX и процессора МС68000.

А какой размер ядра? POSIX совместимость? Компилятор?

Прошу прощения за паузу - погряз в делах. POSIX-совместимости не было  никакой, поскольку не было понятия процесса так как это трактует POSIX. Были скорее конкурентно исполняемые потоки, работающие на общей памяти. Но и задача получить POSIX-совместимую систему не ставилась - задача была втиснуть навигационное ПО в узкие рамки данной ВМ. В качестве компилятора использовался Zortech C++. Ядро было написано на С и ассемблере х86. В библиотеках уже применялся С++. Размер ядра сейчас навскидку не вспомню, нужно откопать тот жесткий диск, где оно хранится. Но весь исполняемый код, без прикладного ПО занимал что-то около 100 килобайт. Точнее скажу, когда вытащу старые исходники на свет  

[jettero]

DDD не относится к именно языку программирования. Часть DDD описывает как надо делать проект, как работать с экспертом предметной области, как выработать общепринятый язык общения, который понимают и эксперт и программист. Используя термины этого языка уже создается модель, которую понимают и эксперт предметной области и программист итд... Это если в двух словах и утрированно, там описано много шагов этого процесса.
Другая часть DDD относится непосредственно к архитектуре, на какие слои разбивать ПО, как интерфейсный слой взаимодействует с моделью, из каких типов объектов должна состоять модель (безотносительно ЯП, а функциональная классификация), какие слои инфраструктуры стоят ниже модели, как эти слои обеспечивают сохранение сущностей модели в БД, без того, чтобы модель "знала" о том как она сохраняется итп... Здесь активно используются такие технологии как ORM, AOP, Persistance. Это опять-таки в двух словах, на 600 страницах там много что рассказано.
Другими словами DDD это некая обобщающая формализация проектирования и стандарт построения архитектуры сложных систем. Сейчас развиваются различные фреймворки, где стандарты DDD подхода уже встроены в библиотеки и это значительно облегчает разработку больших систем.

[Not]

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

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

Другая часть DDD относится непосредственно к архитектуре, на какие слои разбивать ПО, как интерфейсный слой взаимодействует с моделью, из каких типов сущностей должна состоять модель, какие слои инфраструктуры стоят ниже модели, как эти слои обеспечивают сохранение сущностей модели в БД, без того, чтобы модель "знала" о том как она сохраняется итп... Здесь активно используются такие технологии как ORM, AOP, Persistance.
Другими словами DDD это некая обобщающая формализация проектирования и стандарт построения архитектуры сложных систем. Сейчас развиваются различные фреймворки, где DDD подход уже встроен в библиотеки и это значительно облегчает разработку больших систем.

А чем это отличается, от, например, Java Enterprise, где тоже есть и философия, и слоеность, и сохраненияе состояния, и инженер по конфигурированию компонентов и т.д. ?

[jettero]

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

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

А чем это отличается, от, например, Java Enterprise, где тоже есть и философия, и слоеность, и сохраненияе состояния, и инженер по конфигурированию компонентов и т.д. ?

Не понял вопроса. Никто не мешает использовать парадигму DDD программирую на Java Enterprise. Java Enterprise не задает жестко как должна строится архитектура и имплиментировать DDD можно на любом ООП языке.

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

[TAU]

у вас вызвало целый поток критики, что я зеленый, не понимаю, что это такое итп.

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

Я вот уверен, что вы не работали ни с AOP, ни с ORM, ни с Persistence framework, не так ли?

Жонглирование английскими аббревиатурами тоже достаточно ярко вас характеризует. AOP, надо понимать - аспектно-ориентированное программирование? :wink:

Потому что этого всего нету в тех языках которые вы перечисляли

Нету.

Но это все часть архитектуры, которая продвигается в DDD

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

Это и дает мне повод сомневаться в том, что вы знаете о чем спорите. Те общие фразы про DDD, что вы писали, это из какой-то общей статьи про DDD

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

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

[TAU]

Не понял вопроса, это как спросить, а чем .Net отличается от Java Enterprise? там ведь тоже есть своя философия и библиотеки итп.

Вот-вот. Не понимаете вы.  :wink:

В связи с этим и рветесь в бой. А не стоит. Получается - с ветряными мельницами.

На моем, к примеру (и, предположу, общем с Not), уровне понимания между .Net и JEE нет по большому счету глубоких отличий. Ну разве что изначально промежуточный код .Net подлежал компиляции, а Java сначала задумывалась как интерпретируемая. Все равно потом сблизились. Ну и, Java сразу кроссплатформенная, а .Net вроде как не особо - но потом все равно появились некие реализации для Linux, например.

[TAU]

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

Все что вы перечислили выполняется именно на фон-неймановской архитектуре, так что кто-то может упереться и сказать, что ничего нового после Фон-Неймана нету

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

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

Да нет, в определенном смысле вполне оправданно.

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

Да... Трудности понимания или трудности перевода... Собственно, по-вашему, Domain Driven Design надо понимать исключительно в узком смысле как строго конкретную технологию, описанную в "великой книге", на которую вы постоянно ссылаетесь?

думаете, что там ничего нового нету. Это не так

Я так не думаю. Кое-что новое, безусловно, есть. Но, опять же - это в основном мелочи, детали реализации. А основная идея - проблемно-ориентированное проектирование. Давно известное и используемое.
Все, хватит.

[jettero]

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

[jettero]

PS

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

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

[Not]

А чем это отличается, от, например, Java Enterprise, где тоже есть и философия, и слоеность, и сохраненияе состояния, и инженер по конфигурированию компонентов и т.д. ?

Не понял вопроса. Никто не мешает использовать парадигму DDD программирую на Java Enterprise. Java Enterprise не задает жестко как должна строится архитектура и имплиментировать DDD можно на любом ООП языке.

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

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

Да упаси боже. Мне просто любопытно. Я специально сейчас послушал в онлайне лекцию Ивенса по стратегическому дизайну. Очень невнятный дядя, с многочисленными экскурсами и ракурсами, притом что по сути вся его техника, насколько я понял, укладывается в несколько простых правил:
1. работайте на уровне моделей.
2. создавайте адаптеры между моделями и реальным миром.
3. используйте языки характерные для предметной области.

Ну, здорово. Открываем книжку по мат. логике. Читаем. Есть модель, есть интерпретация модели. Открываем книжку по шаблонам проектирования (Design Patterns, читали наверное). Читаем - используйте адаптеры для изоляции вашего приложения от изменений внешнего мира. Ну и так далее. Зато чего у Ивенса много - это философии на тему как "правильно писать программы". Типичное поведение опытного архитектора, наевшегося в свое время проблем, наработавшего набор защитных реакций, воплотив их в конкретном коде (так появляются "framework"-и) написавшего про это книжку.

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

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

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

[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: