I've been thinking about this idea and wanted to know if it's been implemented commercially. Just like there are (external) domain-specific programming languages (where instead of the int's and string's and classes you have business-specific entities and functions that are the primitive types in the language syntax/semantics), is there such a thing as a domain-specific enterprise service bus where instead of routing, orchestrating, and integrating different systems through standard protocols (SOAP/HTTP, JMS, JDBC...etc), you're actually working at more abstract layer of integrating commercial systems (in a specific industry) via their communication protocols? I'm wondering if this pattern has been used as a product for integrating different systems (of different domain standards) within a specific industry (e.g. healthcare, automotive).

Example, in healthcare. You have a central bus that commercial healthcare applications plug into and communicate to each other, get orchestrated, monitored through protocols like HL7, HIE, CCD...etc where the activities, integration, and workflows done through the bus are authored by business analysts (instead of IT staff), example: health quality officers at a hospital, clinical analysts, physicians....etc

In healthcare, this type of integration middleware is called Interface engine.

This is because this type of products are traditionally used by health IT vendors to expose standard-oriented interfaces such as HL7 messaing interfaces.

Consider a EHR vendor, who does not have HL7 expert to implement the interfaces but still wants to integrate with other systems using HL7 or IHE profiles. With an interface engine, along with the expertise provided by their service, the vendor can convert their database interface or SOAP interfaces into standard HL7 interfaces easily.

The market has several players, such as Corepoint, Ensemble, Mirth, etc.

However, these tools are quite focused on the technical level issues, including connecting endpoints, transforming data formats, and routing messages between interfaces, as what you can expect from an ESB. I don't think they are meant to be used by business analysts.