Currently, I'm developing an architecture for a system of the following kind:
There are a couple of existing applications (front end) with which one can define UML profiles capturing some specific domain aspects. Since the tools are proprietary the produced models are not exchangeable by default. On the other hand there are a couple of tools which can analyze the produced frontend models (back end). These also have their own mechanisms (which are different from the frontends) to represent the domain aspects.
Since this would produce m*n model transformations with m frontends and n backends, I chose to introduce an exchange model which captures all relevant information from the frontends and nevertheless allows the backend to have enough information for analysis. This approach results in only m+n transformations.
My bird-eye view on the architecture:
Things go like that:
Transformation is possible between frontend model<->exchange model and exchange model<->backend model. Analysis tasks are triggered in the frontend and are delegated to the backend, where they are executed.
At the first glance, it looked for me like a layered style, but the more I thought about it, the intuition of the problem is not to make different layers exchangeable, where the layers achieve separation of concerns and focus on portability.
It is rather to introduce an intermediate layer, which decouples the two others and targets mainly at extendability. Another point is that the highest abstraction is not found on the highest layer but on the intermediate layer, i.e. the exchange format should be the core of the architecture where frontends and backends can be attached to. It should not need to know anything about its attached frontends or backends. This also means that the backend layer must know how to transform the exchange format into its own model representation, which is a upward usage not allowed in the layered style.
This boils down to the questions:
- Do you know some architectural style which is similar to the one I depicted and also follows its intuition?
- Why isn't this a good example for layered style (apart from the upward usage)?
- Since the application is mainly model-driven, are there some specific architectural patterns/styles for systems of this kind?
Thanks for help in advance!
EDIT: Actually I am concerned with layers, because the coarse vision of this architecture is embedded in an existing project and is communicated there as "layers". But from an architectural point of view, it doesn't fit the style. The problem lies between the documentation and the communication of the architecture. If most of the stakeholders talk about a layered architecture and I introduce the layered view into it, although it isn't applied correctly, wouldn't this confuse all stakeholders, who have the right understanding of a layered architecture?
The goal is to document the views of the style which is really applied to have a correct basis for communicating the architecture.