过度架构等于谋财害命

不说那些不明觉厉的概念，仅仅是列举一下在实际生产（或者说是CRUD……）中经常会出现的过度架构的现象。

其实都不见得是过度“架构”，完全是有样学样，有现成的工程就抄来用，根本没经过自己的思考，没去想需不需要做出改变。

1、万事皆应微服务

微服务、分布式思想的出现，是工程应用上的一个革命性创举。

益处不胜枚举。

但问题是，微服务解决的是工程越来越大，并发越来越重所带来的各种问题。

一个总共三个画面，五个service方法方法，十个SQL的超小型系统，还非要把service和web分开搞成微服务，累不累？

你不累？你不累我还嫌生产环境上占用的服务器多呢！

该“all in one”的就直接“all in one”，现在spring boot做这类事情那么便捷，不要画蛇添足。

2、分层少了都不好意思跟人打招呼

web、service和dao三层，不这么分开，你好意思跟别的同行打招呼吗？

然而去翻翻代码，发现有些service层可能就在干一件事：把从web拿来的参数传给dao，然后dao返回的结果直接扔个web，连编辑的必要都没有。

我甚至见识过一个人的误区：如果不使用三层划分的结构，就没办法使用 Spring 的事务管理。

还是说同样的场景，在面对业务逻辑简单的超小型系统时，能一个类直接把事情解决，并且每个类超不过200行的话，就直接写，分层神马的都是浮云。

开头加上

	@RequestMapping(value = "/queryinfo")
	@Controller

来充当controller。

然后在方法头上加

    @Transactional(rollbackFor = Exception.class)

来启用spring的事务管理。

至于DAO这部分，直接注入JdbcTemplate

    @Autowired
    private JdbcTemplate jdbcTemplate;

然后写几行SQL不就搞定了么。或者干脆使用@Select注解。在业务简单的情况下，SQL能有多复杂，非要放到xml里？

3、接口都不用，你懂研发吗？

承接上一条的分层问题，不光分层，还一定要接口和实现分开，而且一定能说出来接口的种种好处。

“面向接口编程”是一项非常伟大的设计思想，然而我们不是在开发JDK，不是在做框架。

在写接口的时候，先问问自己：真的需要吗？真的能用到接口带来的好处吗？是不是写接口的时间都够把单元测试写完了？

（每次追加方法或者改现有方法的时候，先改interface，然后再粘贴到impl里面，窗口越开越多的时候还是挺想骂人的）

4、以后怎么办？

可能有人会说：你现在这么瞎搞，上线是能用，问题是以后系统扩展、业务规模扩大了该怎么办？

那么，你反过来想一下，当你说“这个问题以后再处理”的时候，那个“以后”有几次存在？

当你说“把这里记录下来，等重构时好好重写一遍”的时候，是不是99.99%的可能性根本没人重构？（没准系统都已经不用了……）

如果今后的系统规模会扩很大的话，那么大概率在初期建设的时候就能预料到。

如果真的发生了呢？那就现改呗，这么一个小系统能有多少内容，而且业务逻辑都写好了的东西，单纯改改结构能费多大的事？就当是架构迭代去处理就好了。迭代的依据，就是遇到的实际场景。

5、商业应用需要的是快和简洁易读

上面提到的做法不是野狐禅，不是特意为了破坏规矩而去放飞自我。

使用框架本身不应是代码复杂化的理由，开发者应该时刻评估自己的做法是不是真的有意义。

从实际情况出发，有时候，去除掉所谓原则性的分层、接口等等的束缚，快速上线才是硬道理。

6、想起来了就再追加一点

在 spring 的早期版本里面，把“什么时候需要什么样的实现”这个问题的解决方案写在了外部的xml文件里面。

你光看java代码的话，根本就不能完全确定注入的东西放在什么地方。

这很符合“解耦”的这一“政治正确”的要求。即使写起来痛苦不堪，天天骂娘。

然后，现在呢？估计spring自己也觉得这样做是需要吃药的行为。