Embora eu possa ver o benefício, não sou muito fã dessas linguagens abstratas. Eles tendem a fornecer principalmente uma boa solução genérica para um problema muito específico, arrendar os que eu vi. Eu acredito que eles não podem se tornar uma realidade tanto quanto eu acredito que arquitetos podem criar arquiteturas ricas e complexas usando nada além de um processador de texto.
Dito isto, acredito que será possível compor sistemas complexos a partir de blocos de construção já feitos. De certa forma, este dia já está aqui, alguns inventaram sua própria linguagem específica e funciona ... um pouco, desde que o aplicativo alvo permaneça no domínio da primeira aplicação da qual o framework foi derivado.
Problemas que podem ser resolvidos pela programação são vastos e, como tal, para criar uma única linguagem que faz tudo, invariavelmente, torna-se insuportável. A idéia de ter uma linguagem de integração para ajudar diferentes sistemas a se comunicarem entre si é boa e definições de protocolos como SOAP, Rest, * RPC tentam alcançar exatamente isso. Alguns são strongs para as interações dinâmicas, mas fornecem pouco para lidar com a modelagem de dados, outros lidam com dados muito bem, mas são fracos para lidar com as interconexões, outros ainda descreverão com precisão o comportamento esperado de um sistema, dando pouca ou nenhuma percepção de como Deve ser feito. Eu acho que o meu ponto aqui é que há sempre uma troca para fazer em algum lugar que irá mover o quadro um pouco mais abaixo no caminho da especialização. Junte isso à vasta diversidade de domínios e aplicativos, torna-se impossível antecipar todos eles para criar uma visão unificada de como uma arquitetura deve ser expressa. Uma arquitetura de software é muito mais do que uma definição estática de componentes que interagem e é aí que a maioria das ACL até hoje falha miseravelmente.
Uma abordagem melhor A IMHO seria criar um modelo aberto e vagamente definido para expressar a capacidade de um componente de forma programaticamente detectável. Um bom exemplo disso seria um moderno editor de GUI. A maioria permitirá a criação de novos componentes que incluem algum tipo de recurso declarativo que o editor pode usar para expor automaticamente o novo componente para futuras composições. A maioria dos editores de GUI atuais se destacam na composição de widgets, mas oferecem muito pouco para expressar as interações dinâmicas desses componentes.
A arquitetura baseada em agentes tentou lidar com esse problema, mas com pouco sucesso. Eu acho que eles estavam à frente de seu tempo, já que a comunicação era um componente central das comunidades de agentes, mas os protocolos e ferramentas para suportar essa riqueza de comunicação ainda estavam por ser projetados.
Até onde sei, a melhor tentativa atual para isso seria Spring Roo . Embora seja específico de linguagem (Java), ele tenta reunir componentes de alto nível separados em um único modelo de arquitetura.
A expressão da arquitetura de um sistema de software é relativa ao seu ponto de vista; A expressão deste ponto de vista conduzirá invariavelmente a uma redução da informação. A expressão de todas as dimensões de uma arquitetura de software é encontrada no código-fonte, mas para "vê-las" é necessário um grande esforço.
Como argumento de encerramento, acho que a criação dessa linguagem está sujeita ao princípio da incerteza de Heisenberg aplicado ao software, quanto mais precisamente você representa um aspecto do sistema, mais você perde os outros aspectos.
meu 2 cent ... pelo que vale a pena com as taxas de mudança nos dias de hoje ...