分层架构_为什么不应该实施分层架构

分层架构

软件中的抽象层是宇航员告诉您的工作。 但是，相反，所有应用程序中有一半会变得如此简单，有趣，并且最重要的是：如果您摆脱了所有这些层，就可以实现高效的实现。

坦白说，您真正需要什么？ 您需要以下两个：

• 一些数据访问
• 一些UI

因为那是大多数系统中不可避免的两件事。 用户和数据。 这是凯尔·布恩（Kyle Boon）对您可能有的选择的看法。

真的很喜欢#ratpack和#jooq 。

— Kyle Boon（@kyleboon） 2014年9月2日

很好，凯尔。 Ratpack和jOOQ 。 您当然可以选择其他任何API。 您甚至可以选择直接在JSP中编写JDBC。 为什么不。 只要您不堆积13个抽象层：

极客和戳的足迹–许可的CC-BY 2.0

这就是胡扯，你是说吗？ 我们需要分层来抽象出底层实现，以便我们可以对其进行更改？ 好，让我们认真考虑一下。 您真正多久更改一次实现？ 一些例子：

• SQL。 您几乎无需将实现从Oracle更改为DB2
• DBMS。 您几乎无需将模型从关系模型更改为平面模型或XML或JSON
• JPA。 您几乎没有从Hibernate切换到EclipseLink
• 用户界面。 您根本不会用Swing替换HTML
• 运输。 您只是不从HTTP切换到SOAP
• 交易层。 您只是不将JavaEE替换为Spring或JDBC事务

不。 您的体系结构可能是一成不变的。 而且，如果-在熵和命运的不可思议的影响下-大约3年前，您恰巧在一个方面做出了错误的决定，那么您无论如何都要进行重大的重构。 如果SQL是错误的选择，那么祝您好运，将所有内容都迁移到MongoDB（本身又是错误的选择，因此请准备好进行迁移）。 如果HTML是错误的选择，那么给您带来更大的麻烦。 发生具体事件时，图层的可能性并没有真正帮助您：95％（因为您错过了重要的细节）

层数=保险

如果您仍在考虑实现一个非常好的分层体系结构，准备处理几乎所有情况，而您只需要将一个完整的堆栈转换为另一个堆栈，那么您真正要做的就是提交十几个保险单。 这样想吧。 你可以得到：

• 法律保险
• 第三方保险
• 再保险
• 商业中断保险
• 业务间接费用伤残保险
• 关键人物保险
• 航运保险
• 战争险
• 付款保护保险
• …… 随机选择一个类别

您可以为可能永远不会发生的事情支付费用并预先付款。 他们会吗？ 是的，他们可能会。 但是，如果您购买所有这些保险，则需要支付大量的预付款。 让我告诉你一个秘密。 如果发生任何事件，您很可能会：

• 没有购买那种特殊的保险
• 没有适当覆盖
• 没看过政策
• 搞砸了

而且，您确实正在每个应用程序中做到这一点，否则这些应用程序将已经完成并且将为您的客户增加价值，而您仍在争论是否在业务规则和转换层之间的第37层上，您实际上需要另一个抽象，因为规则引擎可以随时切换。

别那样做

你明白了。 如果您有无数的时间和金钱，请预先实施一个很棒的庞大架构。

竞争对手的上市时间（途中很有趣）比您的要好。 但对于短时间内，你是接近完美的，分层的体系结构！

翻译自: https://www.javacodegeeks.com/2014/09/why-you-should-not-implement-layered-architecture.html

分层架构