层式应用，但直觉是不同的

Question

目前，我正在为以下类型的系统开发一个体系结构：

有几个现有的应用程序(前端)，可以使用这些应用程序定义UML概要文件，捕捉某些特定的领域方面。由于这些工具是专有的，因此所产生的模型在默认情况下是不可交换的。另一方面，有几个工具可以分析产生的前端模型(后端)。它们也有自己的机制(与前端不同)来表示领域方面。

由于这将产生具有m前端和n个后端的m*n模型转换，所以我选择引入一个交换模型，该模型从前端捕获所有相关信息，但是允许后端有足够的信息进行分析。这种方法只导致m+n转换。

我对建筑的鸟瞰：

事情就是这样的：

前端模型<->交换模型和交换模型<->后端模型之间的转换是可能的。分析任务在前端触发，并委托给后端执行。

乍一看，它看起来像一种分层的风格，但我越想越多，问题的直觉并不是让不同的层可以互换，因为层实现了关注点的分离和对可移植性的关注。

而是引入一个中间层，它主要是在可扩展性的情况下将另外两个和目标解耦。另一点是，最高抽象不是在最高层，而是在中间层，即交换格式应该是可以连接前端和后端的体系结构的核心。它不需要知道任何关于其附加前端或后端的信息。这也意味着后端层必须知道如何将exchange格式转换为自己的模型表示，这是分层样式中不允许的向上使用。

这归结为以下问题：

1. 你知道一些与我所描绘的建筑风格相似的建筑风格吗？
2. 为什么这不是分层风格的一个好例子(除了向上的用法)？
3. 由于应用程序主要是模型驱动的，对于这类系统是否有特定的体系结构模式/样式？

谢谢你提前提供帮助！

编辑:实际上，我关心的是层，因为这个体系结构的粗略视觉被嵌入到一个现有的项目中，并作为“层”在那里进行交流。但从建筑的角度来看，它不符合风格。问题在文档和体系结构的通信之间。如果大多数涉众谈论分层体系结构，而我将分层视图引入其中，尽管它没有正确地应用，难道这不会混淆所有对分层体系结构有正确理解的涉众吗？

其目标是记录样式的视图，这些视图真正应用于为通信体系结构奠定正确的基础。

Answer 1

问题中提出的前端-Exchange后端可以很容易地识别为非常常见的三层方法，通常可以在分布式系统中看到(参见，例如中间件，可能在稍微广义的意义上理解)。

利益相关者之间的共同语言比执行的纯洁性更为重要。例如，许多基于web的MVC系统与理想的即使从一开始就不是MVC相去甚远.在您的案例中，层的含义可以在文档的某些概述部分中解释。

更重要的是，软件体系结构通过在异构前端和后端之间添加抽象层，使系统变得不那么复杂。

在宏级别，您所描述的分层体系结构似乎没有问题。就我个人而言，在您的情况下，我更喜欢基于组件的体系结构，但我想这两者并不是相互排斥的，因为组件可以很容易地被认为是层层排列的。

在微观层面上，看看构造模式，比如适配器、代理和门面。并不是说这些应该直接使用(这取决于您正在构建什么、数据处理模式等等)。模式也依赖于许多阻抗不匹配，在前端和后端之间。例如，不同的操作模式会使连接部件变得更加困难(例如，如果一个前端使用“推送”技术，另一个使用“拉”技术，第三种使用批处理模式每天运行一次任务/转储数据-我在其中一个应用程序中遇到了这种情况)。

从您的问题来看，不太清楚您的应用程序是使用UML模型构建软件，还是将UML转换成代码的最终结果(或者它甚至是UML的运行时解释器？)在任何情况下，都需要粘合，由此产生的体系结构在这两种情况下都可能非常相似。

模型干燥是，IMHO，正交的建筑的层次性.但是，如果这是您的意思的话，我不太熟悉模型驱动体系结构。在这方面，解决方案的准备部分限制了您的体系结构选择。如果我很好地理解这个问题，那么您有几个DSL(每个前端使用不同的UML)。

总之，很难从已经高度抽象的概述中建议合适的体系结构抽象。然而，他们的建议是忘记纯洁，更加注重实用性。