Size: a a a

Архитектура ИТ-решений

2019 August 25

S

Sergey in Архитектура ИТ-решений
так же работоспособен вариант с генераций сегментов кода помеченных комментариями где юзер может править.

А более сложные варианты когда меняем код, потом парсим, строим модель и мержим ее с исходной моделья для включения юзерских правок в генеренном код иногда работают (сам делал 😁 ) но могут глючить
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
кодогенерация оптимальна для тех случаев, когда внутрь сгенеренного кода уже не лезут, а кастомизации задаются в исходном коде (вставки таргет кода). Типичный пример - все генераторы парсеров, лексеров, аст-ов.  Или протоколы аля gRPC,  языки сериализации типа ASN.1 и т.п
Да. Но это не бизнес-приложения, где логика может меняться в самых неожиданных местах. И нет данных. В том же gRPC нужно очень внимательно смотреть за обратной совместимостью.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
так же работоспособен вариант с генераций сегментов кода помеченных комментариями где юзер может править.

А более сложные варианты когда меняем код, потом парсим, строим модель и мержим ее с исходной моделья для включения юзерских правок в генеренном код иногда работают (сам делал 😁 ) но могут глючить
Ага, так раньше делал NetBeans, Delphi и другие IDE с визуальным программированием
источник

S

Sergey in Архитектура ИТ-решений
прийдя из несколько иного мира в мир бизнес-приложений я не заметил больших отличий. Просто одни вещи другими словами называете и мало кто может парсер написать :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Атогенерация отлично работает во многих инфраструктурных тулах
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
прийдя из несколько иного мира в мир бизнес-приложений я не заметил больших отличий. Просто одни вещи другими словами называете и мало кто может парсер написать :)
Разница огромная) парсер работает по чётко заданной формальной логике. Его "мир" детерминирован. А изменения бизнес-логики невозможно предусмотреть, иногда они противоречат всякой логике и здравому смыслу)
источник

S

Sergey in Архитектура ИТ-решений
Gennadiy Kruglov
Разница огромная) парсер работает по чётко заданной формальной логике. Его "мир" детерминирован. А изменения бизнес-логики невозможно предусмотреть, иногда они противоречат всякой логике и здравому смыслу)
да я бы не сказал что  изменения бизнес-логики настолько уже недетерменированы. В качестве метамодели все равно можно взять асинхронные абстрактные автоматы да сети Петри (activity/BPMN) . Ну не обязательно так реализовывать, а смотреть на бизнес процессы с такой точки запросто
источник

S

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
да я бы не сказал что  изменения бизнес-логики настолько уже недетерменированы. В качестве метамодели все равно можно взять асинхронные абстрактные автоматы да сети Петри (activity/BPMN) . Ну не обязательно так реализовывать, а смотреть на бизнес процессы с такой точки запросто
И в сетях и в BPMN есть узлы. В BPMN, например, задачи (tasks). Вот внутри них обычно куча логики. Это сервисы, грубо говоря.
источник

S

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
На самом верхнем уровне всё детерминировано. Решение - чёрный ящик. А лучшую архитектуру придумал Малевич в 1915 году
источник

S

Sergey in Архитектура ИТ-решений
это уже философия. Чтоб видеть черный квадрат, надо чтоб вокруг было нечто иное. Тем самым квадрат предполагает наличия инобытия для своего бытия
источник

S

Sergey in Архитектура ИТ-решений
формализация подходов не означает детерменизм. Хаос, нелинейные системы вполне себе моделируются. Важно лишь выбрать подходящие модели...
источник

P

Pavel in Архитектура ИТ-решений
Gennadiy Kruglov
И в тоже время, когда аналитики описывают структуру БД, они это делают скорее "для себя". Потому что хорошие разработчики всё равно сделают по-своему.
Конечно.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Sergey
я был частью команды  IBM Rational Software Architect, это коробочный продукт. Сейчас можно сказать что изначальных девелоперов там не осталось, лишь мелкая кучка индусов. Те кастомеры, кто оказался завязан на него страдают. Благо что это был Эклипс и кой что сами могут допиливать. На счет "уйдет" - IBM просто взял и продал весь Rational индусам
Здесь стоит упомянуть про "горизонт планирования развития". Если владельцы бизнеса планируют (!!!) развивать бизнес много лет, то MDD имеет шансы себя оправдать. Года через 2-3, ну и далее.
Если у нас "всё внезапно" и непредсказуемо в компании на горизонте 5 лет (хотя бы) то MDD конечно смысла имеет мало. На коленке в табличках будет проще.
источник

S

Sergey in Архитектура ИТ-решений
Alexander Luchkov
Здесь стоит упомянуть про "горизонт планирования развития". Если владельцы бизнеса планируют (!!!) развивать бизнес много лет, то MDD имеет шансы себя оправдать. Года через 2-3, ну и далее.
Если у нас "всё внезапно" и непредсказуемо в компании на горизонте 5 лет (хотя бы) то MDD конечно смысла имеет мало. На коленке в табличках будет проще.
да вот те кто вложился в Rose, потом (с трудом!) перешли на Rational Software Architect (как идеологического наследника), те планировали на много лет. В итоге и получили многолетние проблемы и страдать им еще несколько лет, я думаю.  И это крайне крупные конторы :)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Я специально разделяю business owners и business executives здесь. Директорат может что-угодно планировать. Но деньги собственника и решение - его.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Sergey
да вот те кто вложился в Rose, потом (с трудом!) перешли на Rational Software Architect (как идеологического наследника), те планировали на много лет. В итоге и получили многолетние проблемы и страдать им еще несколько лет, я думаю.  И это крайне крупные конторы :)
Конечно здесь важна стратегия развития инструмента, предлагаемая вендором. Завязка на внешнего подрядчика всегда риск.
источник

S

Sergey in Архитектура ИТ-решений
молодежь не хочет идти в Modeling. Про это нам ряд клиентов гооврил, что молодежь не хочет работать на проекте с MDD. Для них это тоска и муть. А  если нет притока свежей крови, то все умирает
источник

S

Sergey in Архитектура ИТ-решений
в западных универах интерес к MDD тоже угас в целом
источник