Э

Я пока в голове такую схему наметил - рисуем uml диаграмму( или в спарке EA)  со схемой интеграции данных между системами. На ней указываем правила трансформации данных на метаязыке. Далее экспортируем в xml или ещё какой то формат, скармливаем это интерпретатору на нужном языке. Он из шаблонов модулей на целевом языке эти модули кастомизирует и выстраивает в цепочку единой ответственности. Это все билдится и уходит на прод.

Таким образом все проектирование идёт в соответствии с архитектурой этих шаблонов, которая изменяется по принципу open-close. И нет инжекций в продовый код, не согласованных с архитектурой

#программистынинужны

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

вы кратко и метко описали всю суть MDA :)

Какие задачи хочу решить - - отвязаться от платформ потоковой обработки, чтобы выбирать их из каталога или менять. Сейчас. Идёт проектирование фактически code first
-

Хочу сделать contract first

Хочу мастер данные и мета данные убрать в справочник

Ну, тут не будет contract first, так как ни uml, ни маппинг полей не дадут описания контракта.
Проще уж стандартизировать подход к реализации интеграционных шлюзов и после трех-пяти реализаций выработать DSL.
Это будет и гораздо дешевле и гораздо эффективнее.

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

А цель-то какая? Ускорение разработки, уменьшение стоимости поддержки, уменьшение требований к персоналу? Какую бизнес-цель достигаем?

Ну да это и выльется в dsl

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

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

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

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

Зато появляются знания в домене которых не было и которые можно переиспользовать

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