通过窥镜建筑反模式

反模式是无效或适得其反的通常重复出现的软件设计模式。 我多次看到的一种建筑反模式就是我称之为“通过玻璃”模式。 之所以这样命名是因为API和内部表示形式通常由其使用者反映和定义。

此模式的核心是，软件组件的拆分方式以不适当的方式耦合多个组件。 一个示例是在“前端”和“后端”之间划分的软件，但是它们都使用相同的接口和/或值对象来完成其工作。 这导致了几乎每个后端更改都需要前端更改而反之亦然的情况。 作为特别痛苦的示例，请考虑使用GWT（通常）或尝试通过javascript使用SOAP API。

这种模式还可以通过多种其他方式显示出来……最常见的是团队结构问题。 人们将因他们的技术专长而分裂，但随后会阻碍进步，因为需要进行数据库更改的DBA不了解前端应用程序的需求，因此前端开发人员最终会花费大量时间进行“远程控制”数据库团队。 也可能希望向前端应用程序公开一组Web服务API，但是由于仅前端应用程序存在后端服务调用，因此最终会出现许多鸡肉和鸡蛋的情况。

在几乎每种情况下，该问题的解决方案是＃1添加翻译层，＃2＃1简化设计，或＃3重组工作，以便可以逐个组件地对其进行隔离。 在上面的Web服务示例中，对前端使用直接集成并在完成前端工作之后公开Web服务可能更合适。 对于数据库问题，DBA可能应该与前端开发人员一起嵌入，并在屏幕设计中提供“帮助”，以便他们对正在发生的事情有更完整的了解。 解决数据库问题的另一种方法是允许前端开发人员构建初始数据库（如果他们具有专业知识），并允许DBA调整设计后言。

我发现，除非试图解决方案空间的范围和规模受到明显限制，否则在层与层之间添加转换层通常比尝试统一设计最容易，最经济。 我之所以这样说，是因为现代的快速开发框架（[g] rails，play ...）现在以非常简单的方式支持了这一点，并且没有理由不这样做……除了无知之外。

翻译自: https://www.javacodegeeks.com/2014/07/through-the-looking-glass-architecture-antipattern.html