AR>>Да, сегодня архитектура и код оказались разъединенными. Но вот каким образом их соединить? Представляется три возможных варианта: AR>>1) Расширить возможности UML и инструментария для работы с ним, включив в него возможности для встраивания исходного кода непосредственно в UML-модели (путь описанный _Obelisk_). В таком варианте исходный код может автоматически генерироваться прямо из полной UML-модели.
N>Ужаснейший вариант, просто страшно становиться если это кто-то сделает... чем это лучше RAD-средств, абстракция иная только. Представляете как с этим работать...
Уже сделали. Вполне нормально получается. Просто есть задачи, где UML можно и нужно использовать в качестве языка разработки.
В прошлом, такое делалось и для других языков спецификаций. Визуальные CASE-средства для языков типа SDL или TTCN уже больше десятка лет существуют. А они как раз позволяют встраивать исходный код в модели. CASE-средства эти вполне успешно применяются при разработки очень крупных программно-аппартных комплексов. UML — просто закономерное развитие этого процесса.
Беда в том, что в России программисты с этим почти не сталкиваются, ввиду отсутствия серьезных производителей всякой высокотехнологичной электроники.
Здравствуйте, Сомов Александр, Вы писали:
СА>Всё-таки, даже если в математических книгах и есть картинки, то они описывают не структуру формул, а, грубо говоря, результат их применения. А вот тот же UML — описывает как раз-таки более структуру. Аналогом картинок из математических книг в программировании были бы screenshot'ы.
Ага, например, скриншоты библиотеки какой нибудь нейросетевой ...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, byur, Вы писали:
B>> Вы просто выражаете свои проектные мысли на этом языке ... это несколько удобнее, например для обсуждения проектных решений, чем использование кода ... особенно, если мы еще до кода не добрались. M>Чем может быть удобнее два языка, когда можно обойтись одним?
В том-то и дело, что не удается обойтись только чем-то одним ... цели у языков разные. Для проектирования, например бизнес-систем, не нужны подробности, которе есть в исходниках. И проектировать я предпочитаю не в коде ...
Здравствуйте, _Obelisk_, Вы писали:
_O_>Уже сделали. Вполне нормально получается. Просто есть задачи, где UML можно и нужно использовать в качестве языка разработки. _O_>В прошлом, такое делалось и для других языков спецификаций. Визуальные CASE-средства для языков типа SDL или TTCN уже больше десятка лет существуют. А они как раз позволяют встраивать исходный код в модели. CASE-средства эти вполне успешно применяются при разработки очень крупных программно-аппартных комплексов. UML — просто закономерное развитие этого процесса.
Полностью поддерживаю.
Всегда можно придумать такую ситуацию, где самое совершенное средство будет не эффективно. Если вам нужно распечатать ОДНУ платёжку и в ЕДИНСТВЕННОМ экземпляре то программирование в этом будет только мешать. Теперь в стиле критике UML можно сделать далеко идущие выводы...
_O_>Беда в том, что в России программисты с этим почти не сталкиваются, ввиду отсутствия серьезных производителей всякой высокотехнологичной электроники.
Именно. У нас привыкли думать, что мы тут крутые, потому что бухгалтерский софт писать умеем, а ведь в мире делается полно такого о чём у нас зачасую или вообще не имеют представление или имеют очень смутное представление. Взять те же САПР. Или суперкомпьютерные приложения. У нас об этом слышал один из деясти, ну а работал в этой области один из десяти тысяч, если не из миллиона. Но зато все уверенно рассуждают о том, что UML там не нужен.
Здравствуйте, Сомов Александр, Вы писали:
СА>Я вот проектировщик/архитектор. И мне проще выделить базовый код архитектуры, чтобы он не перемешивался с остальным, чем строить абстрактные схемы "не ... на уровне кода". Более того, иногда приходится следить, что архитектура соблюдается. И тут опять же, без выделенного уровня будет тяжело.
Каждый работает так как ему удобней ... в многообразии -- единство
B>>Выдержка из вашего сайта о вас же ... СА>Я, хоть во многом с Mystic'ом не согласен, но, всё же, это уже переход на личности. Вам что, кроме этого, больше нечего сказать по содержанию?
Просто это аргументация бессмысленности дискусси конкретно с этим участником ... и все.
СА>В любом случае, до определённых пределов можно соблюдать такую коммуникацию, что UML не нужен. Обычный язык достаточно эффективен. Следом, по эффективности, идёт код. А затем только формальные картинки. И вот архитектор должен хорошо владеть этими средствами в перечисленном порядке.
Что есть эффективность? Эффективность эффективности рознь ...
B>>Толк это вещь сложная, неопределенная и непонятная. Проще говорить что Domain Model по определению вообще независит от реализации . N>я конечно понимаю, что знание какого либо языка (даже UML) не обязательно для описания процессов происходящих в жизни, буть то тех-процессы, бизнес-процессы, то что описывает автоматизируемую систему, в случае автоматизации чего-либо, но ведь это не архитектура ПО.
Интересно, в чем отличие "тех-процессов" и "бизнес-процессов"? А кто говорит, что описание БП есть архитектура???? Что-то я такого в этой ветке не встречал ...
N>И безусловно из вашей модели предметной области ну никак однозначно програмную систему построить нельзя, без промежуточных этапов проектирования. А знания языка, ОС, и прочего на этапе проектирования для реализации по-моему просто необходммы... Как вы будете проектировать 3D реадктор скажем, не зная о сушествовании OpenGL и DirectX, а также их особенности, или как
Стоп ... я думаю, что все прекрасно поминамают, раз дискутируют о применимости UML и вопросах методологий, где он используется, в каких случаях эффективно строить Domain Model а в каких нет, это даже в Rational Edge писали, году в 2001 кажись ... и конечно же знаете, что есть таки отличие в системах для автоматизации деятельности организации и например, офисными приложениями или как в вашем случае 3D редактора. Кроме этого, как я говорил Domain Model относиться к Модели анализа, а не дизайна ... . Так что IMHO не вполне корректный пример.
N>вы будете проектировать не зная что в C++ возможно множественное наследование, а в Object Pascal нет, и даже наследование интерфейсов не возможно множественное. Модель модели рознь, и
Именно, это важно только при построении Platform Specific models ... как я говорил что можно жить даже в модели дизайна (при наличии определенной квалификации) без этого. Кстати это часто демонстрируют на презентациях своих продуктов их производители (IBM так точно показывал, лично тов. Сперанский приезжал из Франции ...)
N>моё мнение таково что модель должна быть построенна так чтобы максимально описывать объект с минимальными затратами на её создание. Я не уверен что описание бизнес-процессов в производстве удобнее представить в виде UML, и затем демонстрировать это управляющему производством или президенту автоматизируемой компании... или вы их UML обучать будете...
Наша пiсня гарана, нова (укр.)... Открою вам один секрет ... ни один руководитель организации-заказчика, в моем опыте, даже не взглянул на описания бизнес-процессов дольше чем 2 минуты, не зависимо от нотации в которой они были смоделированы. Максимум они читали 10-страничный Vision. Более интересно, с вашей т.з., видимо им показывать исходные коды ? Я утририю конечно, но тем не более . Кроме этого, я уже писал, что бизнес-моделирование (БМ) бизнес-моделированию рознь ... использование UML или IDEF или ARIS или ... сильно зависит от целей этого БМ. Если моя цель просто понять, как происходят процессы, какими сущностями они оперируют ... и это для целей только автоматизации а не реинжениринга -- то ничего мне не мешает это описать на UML. А если я могу использовать подход с бизнес-юзкейсами, то при желании могу и без UML динамику бизнеса описать .
B>>>>1. Чтобы сначала увидеть лес, а потом интересующие меня деревья. N>Кстати, а что если лес в этом месте в силу ограничений систмы, платформы или языка посадить нельзя, что если это взлётная полоса, а вы не знаете таких особенностей в силу того что не считаете нужным знать ещё какие-то там особенности систем или языков, а заказчик тоже знать не может...
Тогда еще на фазе Inseption (это из RUP) мы скорее всего откажемся от создания ПО . А вообще это становится 100% очевидным при формировании требований к ПО. Т.е. когда дизайн только начинается в параллель требованиям.
B>>>>ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной??? N>1) взять документацию по системе. А если вам нужно внедрение в систему или переработка, взять книги по SmallTalk, изучить Smalltalk.
Кто это будет оплачивать??? (Время-деньги).
N>p.s. Я не утверждал что использовать UML не возможно или нельзя, я говорил что пользоватся средствами создания и поддержки UML-проектов крайне не удобно, перенося это на язык я говорил что UML (как методологией) пользоваться также не удобно. Безусловно ей пользуются, потому что
1. UML это не МЕТОДОЛОГИЯ!!!!!
2. А вот как раз при методологическом подходе, использовать UML становиться очень удобно. Особенно когда а) хорошо знаешь UML б) хорошо знаешь методологию в) хорошо знаешь инструментальные средства.
3. А если работать без методологии, и при этом искать нечто "что бы мне позволило выразить мое понимание и видинье системы" -- то вполне допускаю, что UML не совсем то, что вы от него ожидаете . Отсюда и тяга к демонстрации кода. Не спорю, код может быть с "мыслями внутри".
4. По-большому счету -- никто не говорит, что UML rulez forever. Но это лучше чем собственные измыслы ..., а код нужен для своих целей. В конце концов есть методология XP, которая "кодоориентирована", но и она имеет собственную область применения и условия применения. "Каждому проекту -- своя методология" (с) А. Коберн. Если бы дискутирующие апелировали к ней, и имели солидный опыть использования в проектах XP, я бы еще это воспринял .
N>лучшего нет, хотя сомнительно ибо карандаш-бумага иногда всё таки выразительней и понятней для всех участников, особенно небольшой команды. В больших работать не довелось и спорить я не буду на эту тему. Я просто глубоко уверен что можно создать средство значительно удобнее UML, но к сожалению до сих пор не создано, вероятно потому что одни считают его вовсе не нужным, другие свято верят в его идеалистичность.
Просто все что нужно -- уже создано ... только нужно уметь им пользоваться ... и знать, в каких случаях что лучше.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Целиком поддерживаю, когда речь идет именно о процессе разработки. Использовать методологии UML для разработки неудобно и накладно, а тем более в небольших проектах. Нужны иные средства (Together и DSL вероятно как раз и есть движение в нужном направлении). В то же время нет
Ну вот приехали ... додискутировались до того что есть "методологии UML" !!! И до того что Together НЕ ИСПОЛЬЗУЕТ UML!!!!
AR>никакого смысла заменять UML как средство визуализации. Возвращаясь к своей аналогии с PDF замечу, что все согласны использовать PDF-документы, когда надо обеспечить народ информацией. Но вот писать тексты сразу в формате PDF никто особо не стремится — все больше Word или другие текстовые редакторы пользуем.
СА>Насчёт доводить — функциональные требования нужны всегда, а с ними — да, возьмусь. В этой области UML один из инструментов описания и даже не самый удобный.
Вау ... это ж где говорилось про то что требования к ПО можно на UML выражать???
СА>А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено. Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний.
Есть! Есть достаточно грамонтно (для своего времени) написанный код ... а именно ядро АБС ... пришла новая команда разработчиков ... документации ноль ... голый код на Visual C++, да с комментариями, да инкапсулировано все в классы ... и ребятки пришли грамотные ... однако в беседе со мной говорят, о том что им очень не хватает диаграмм для понимания всего этого ..., и первое про что они сказали ... да да ... про UML ... вот вам и пример.
Здравствуйте, Сомов Александр, Вы писали:
СА>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?
Хм ... а сколько у Вас лично ушло времени на освоение собственно UML????
Здравствуйте, nixite, Вы писали:
N>p.s. кстати на Use Case мне откровенно смотреть проивно ибо кажется поделкой из десткого сада. Его целесообразность вообще мне сомнительна. Текстовый документ описывающий всё тоже самое более подробно и ясно, займёт меньше места, сэкономит бумагу и время.
Вот вы и попались на незнании ... а если бы знали методологию (например RUP) то сказали бы, что просто диаграммы юзкесов в UML без спецификаций юзкейсов это откровенная БЕЗГРАМОТНОСТЬ. Я бы взглянул на эти диаграммы, с вероятностью 0,8 UC еще и неверно выделены ... UC это в первую очередь ТЕКСТ ... а диаграммы всего-лишь его графическое оглавление. Это нужно знать, прежде чем дискутировать о применимости UML. Есть конечно же и другие возможности описания юзкейсов с использованием других диаграмм UML .
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Сомов Александр, Вы писали:
СА>> Однако, это верно для очень квалифицированного программиста. M>Естественно, но лично я с турдом себе представляю архитектора, который не является квалифицированным программистом...
А я вот лично знаю пару ... (один канадец, а другой англичанин) ... которые не являются квалифицированными программистами, но зато они хорошие архитекторы, и их приглашают на серьезные проекты именно как архитекторов ...
AF>> А на самом деле — обычный старший программер... M>Хоть горшком назови, какой тол от рахитектора, который кроме рисования диаграмок ничего не умеет?
Про толк же мы вроде выяснили ... что это вешь очень непонятная и неконкретная ...
Тогда не говорите про архитектуру ... а говорите про имплементацию требований, архитектуры и дизайна -- ее то как раз код и отражает в первую очередь
Здравствуйте, Сомов Александр, Вы писали:
СА>Я правильно понимаю, что модель анализа — это ещё вовсе не архитектура классов? А всего лишь чётко выделенная структура предметной области?
Я при всем желании не могу ответить на ваш вопрос, ибр искренне не понимаю, что кроется под термином "архитектура классов" ... я такого не встречал в литературе
СА>И то, что модель дизайна может быть независимой — это накладывает ограничения общность её описания? Т.е. я так понимаю, там не должно быть подробного описания взаимодействия объектов. Скорее уж описание модульного разделения системы и взаимодействия модулей. Так?
Чтобы ответить на ваш вопрос корректно, мне нужно понять, какой методологией, или каким набором знаний, вы руководствуетесь рассуждая о программной архитектуре? Просто я бы смог исходя из ваших знаний попытаться вам это пояснить. Как я понимаю из вашего вопроса с RUP вы не знакомы совсем. Это так?
Исходим из того, что с паттернами дизайна вы таки знакомы. Тогда ответим так -- при построени модели анализа (а там используются в т.ч. и диаграммы классов UML) мы не определяем, что счет и его айтемы, например, или др. сущности выражаются через петтерны типа observer, facade и т.п. ... это будет в модели дизайна.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, ВСЕ УЧАСТНИКИ ОБСУЖДЕНИЯ, Вы писали:
B>Господа! Предлагаю определится с терминологией! А то, похоже, каждый под архитектурой понимает что-то свое: B>кто бизнес логику, кто иерархию объектов, etc.
B>Ну вот приехали ... додискутировались до того что есть "методологии UML" !!! И до того что Together НЕ ИСПОЛЬЗУЕТ UML!!!!
Ну словили на слове. Конечно надо было написать "методологии, предполагающие использование UML". Что же касается Together, то конечно UML там есть (я ведь и не отрицаю необходимость UML вообще), но как-то это несколько по-другому что-ли, чем например в Rose. Он там как-бы на вторых ролях или уж во всяком случае не главнее собственно кода. Хотя я и не говорил, что Together это именно то, что нужно. Но некоторые моменты (лучшие средства синхронизации UML-моделей и кода) позволили мне сказать, что это "движение в нужном направлении".
Здравствуйте, Алексей:
AR>Здравствуйте, byur, Вы писали:
B>>Ну вот приехали ... додискутировались до того что есть "методологии UML" !!! И до того что Together НЕ ИСПОЛЬЗУЕТ UML!!!!
AR>Ну словили на слове. Конечно надо было написать "методологии, предполагающие использование UML". Что же касается Together, то конечно UML там есть (я ведь и не отрицаю необходимость UML вообще), но как-то это несколько по-другому что-ли, чем например в Rose. Он там как-бы на вторых ролях или уж во всяком случае не главнее собственно кода. Хотя я и не говорил, что Together это именно то, что нужно. Но некоторые моменты (лучшие средства синхронизации UML-моделей и кода) позволили мне сказать, что это "движение в нужном направлении".
Позволю себе не согласиться с тем, что в Together UML "вторичен". Действительно, код с точки зрения тех редакций Together (Developer и Architect), которые ориентированы на проектирование — является "first class cictizen" и технология LiveSource действительно не заставляет хвататься за сердце (боясь потерять то, что написано руками) когда делаются изменения в модели и и получаем изменения кода.
В то же самое время, есть Together Designer — как самостоятельная "среда", так и встраиваемая в VS.NET, Eclipse (Analyst view в Together Edition for Eclipse), JBuilder или в близком будущем — в Delphi. Together Designer — "чистое" моделирование и проектирование на UML 1.x и UML 2.0. И UML в нем — на главных ролях
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>>И кто определяет ложность аналогий? M>Аналогии ложны все..
Угу. То есть и все ВАШИ анологии — тоже ложны
AF>> Хорошо. Как спец по микроэлектронике — могу легко подсунуть тебе схемку на пару десятков процов и FLEX кристаллов. Разбирайся как с ней работать по этой самой схемке M>Ну, про аналогии я уж еговорил...
Это не аналогии. Это повседневная практика некоторых проектов.
AF>> ты от всех остальных стало быть требуешь вступления в джедайский орден? M>Вовсе нет, я хочу чтобы мне внятно объяснили зачем UML нужен. Два способа использования меня уже вполне устроили, но в остальном пока увы...
Объясняли миллион раз. Что бы описать некоторые аспекты модели общяпринятым, стандартным образом.
Здравствуйте, Сомов Александр, Вы писали:
AF>>>>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать? СА>>>Не так, 10% кода должны отражать логику работу, а 90% — нюансы. AF>> Про должны — это теория. А если не отражают? А если, как это часто бывает, зказчик хочет, что бы сначала заработала часть функционала, а потом делалось всё остальное — и именно этот кусок + обвязка которая ему нужна и реализованы? СА>Да какая разница — какое там отношение процентное. Просто код, отражающий нюансы, должен быть инкапсулирован. А то, что останется — читать несложно. И поддерживать несложно.
Прямо как классики марксизма-ленинизма. Коммунизм должен быть построен. Есть большая разница между "должен" и что есть на самом деле. Вы и картинки в код поместите?
СА>А что касается написания части функциональности — есть две модели: гибкая и негибкая. В первой мы не будем писать дополнительный код сверх части функционала (тоже неплохо, а вдруг потом заказчик обанкротится, а так — мы не затратим лишних усилий ), а во второй — запланируем сразу. По моим ощущениям (даже и не расчитывайте на объективность мнения ) — временные затраты в первом случае (плюс рефакторинг и доведение до полного функционала) и во втором случае (полная архитектура, часть функциональность, доведение до полной) будут примерно одинаковы. А вот риск в первом случае вроде как меньше. Хотя он тоже растёт с ростом величины проекта.
И что? Как это связано с документированием или не документированием модели (с использованием или без использования UML)?
СА>>>Насчёт доводить — функциональные требования нужны всегда, а с ними — да, возьмусь. В этой области UML один из инструментов описания и даже не самый удобный. AF>> То есть тезис о том, что кода достаточно вы только что сами же и отвергли... СА>Для понимания архитектуры — достаточно, для развития и исправления дефектов — недостаточно.
А если от архитектуры только кусок?
Почему то вы забыли о том, что бывают весьма интересные и оригинальные решения — от алгоритмов до архитектуры — ценность которых гораздо выше, чем того (часто кривого) кода, который их реализует?
СА>>>Опять же, из функциональных требований, которые сами по себе не требуют UML. AF>> Да, как уже многократно говорилось, обойтись можно. И в зависимости от ситуации это будет разумно использовать UML или не использовать. СА>Ну вот. А я предлагаю структурировать код, чтобы и архитектура (не функциональные требования) им же просто и описывалась. Чтобы этот не очень удобный инструмент (UML то есть) и вовсе не был нужен.
И помещать туда тонны текста, картинок, диаграмм?
СА>>>А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено. AF>> То есть нужна документация описывющая модель. СА>>>Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний. AF>> Система может быть написана плохо и действительно не отражать модель. Но ценность часто имеет именно модель, а не сам код — особенно в крупных проектах. СА>А как хорошо, когда там ещё и код модель отражает.
Да что вы в код то вцепились?! Прям как дети! "Вася смотри какой я класс состряпал". Половина оболтусов на форуме так и выступает.
Поймите, часто бывает ситуация, когда есть проект, который тянется годами, когда изначально не ясно, что делать, а делать что-то надо. И в этой ситуации — система пишется, притом, естественно, весьма далеко от идеала, но это всё хозяйство сертифицируется и отправляется клиентам — ибо бизнес не ждёт. И вот проходит 2-3-4 года за которые наконец-то становится ясно, что и главное как нужно делать. Если всё это время строилась модель — на уровне бизнес-процессов, на уровне UML моделей, на уровне толковых описаний, то это даёт возможность переписать систему грамотно — с использованием более современных технологий. Так вот эта модель — квинтэссенция опыта — стоит гораздо дороже, чем весь написанный код.
В чём здесь роль UML? Да в том, что опыт накапливается годами, времени писать романы нет. А вот накидать диаграммку с пояснениями возможно. Люди приходят и уходят. И через 2-3 года найти концы почти не реально. И если не использовать UML (или любую другую общепринятую систему обозначений) — то у кого потом спрашивать, что имел в виду автор диаграммки 3 года назад?
Придумать систему обозначений, да ещё её задокументировать (по сути разработать стандарт) — эта работа может быть сопоставима по объёму с самим проектом. И ради чего? Ради фанатичного нежелания учить UML? Или ради высокомерного самомнения — что всё сделаем лучше?
СА>Мы же не говорим о том, как быть с уже написанной лапшой, мы говорим, как писать код так, чтобы он не требовал (или требовал минимум) подобных дополнений.
Ещё раз. Часто код сразу пишется для мусорной корзины — потому, что его просто не возможно сразу писать хорошо. И его единственное предназначение — выработать модель, которая будет нужна в дальнейшем.
Здравствуйте, Сомов Александр, Вы писали:
AR>>Все-таки не стоит путать требования и уже разработанную базовую архитектуру системы. Одни и те же требования можно выполнить в рамках разных архитектур. Но когда речь идет о воплощении именно какой-то конкретной архитектуры, то описание требований должно быть дополнено и описанием этой архитектуры.
СА>Мне, всё таки, кажется, что это просто разные вещи: описания требований и описания архитектуры. Можно работать с незнакомым кодом при наличии первого и отсутствии второго, но не наоборот.
Если код среднего качества — тем более не завершённый, то в этом случае (если нет информации об архитектуре) — его проще выкинуть или по частям переписать — в соответствии с требованиями.
Здравствуйте, Сомов Александр, Вы писали:
СА>>>А по вашему код должен выглядеть совсем не так? Мой код структурно очень близок к предметной области. И тут можно выделить последовательность взаимодействия в виде высокоуровневых операций в коде.
AF>>То есть в твоём коде отсутствуют ключи, идентификаторы, указатели или ссылки — в общем всё то, что отсутствует в предметной области? AF>>Интресно — и как он при этом работает?
СА>Хм... да ведь это же всё, что запятые в тексте. Читать-то нисколько не мешают.
Не мешают, когда они расставлены по смыслу и помогают воспринимать текст. А вот когда они там не по делу — мешают и ещё как.
СА>Вот когда там появляется дополнительная логика или нюансы — это хуже. Они скрывают общую логику. Ну так их можно отделить, инкапсулировать во что-нибудь, чтобы в глазах не маячили. А основной код остаётся лакончным и близким к предметно области.
А как с быть с оптимизацией по производительности?
В итоге вы следуя своей, изначально неверной идее, просто напишете код низкого качества. Вот и весь результат.
Это тоже самое, если в телевизоре, холодильнике или автомобиле на каждой детали, даже самой маленькой детали — приклеивать том с описанием технологии её производства.
СА>К тому (можно я тоже попередёргиваю ) — в предметной области, как правило и стрелочек с рамочками нет.
В том то и проблема, что сначала требуется построить адекватную модель предметной области — что бы потом по ней можно было построить модель программной системы.
...
что это вешь очень непонятная и неконкретная ...
