那么问题来了，怎样算美？
部门招人不需要通过部门同意吗？

@warcraft1236
The Spring Framework is an application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE (Enterprise Edition) platform. Although the framework does not impose any specific programming model, it has become popular in the Java community as an addition to, or even replacement for the Enterprise JavaBeans (EJB) model. The Spring Framework is open source.
另外推推荐去读下 j2ee development without ejb 第七章

@NeinChn 你知道 getter setter 原理，适用场景，风险吗？出了问题你能快速解决么？

楼上这群人写 web 写傻了吧，spring 的是什么都不知道

推荐一本正在看的代码大全

@Orciorc 3000 流明我觉得就够用了，家用市场 4000 多就可以入门了

上投影吧，刚上车，真香

gradle 好，gradle 有学习成本，学 gradle 就要学 groovy，如果不学习用的不明不白的不如用 maven 了，起码没有一些黑魔法，为了学习一个构建工具学一门语言相对来说要求有点高。
接触过一些 android 同学只会 copy 配置。灵活构建没有得到体现。
如果全员都会 gradle 我也相信很少有人会用 maven。

2，单元测试不涉及到数据存储，不存 3 在脏数据的问题，更多是对充血模型中对象里业务“动词”的测试，断言“名词”属性就可以了。
集成测试可以使用 rollback 处理脏数据问题。
4，看你的结构上有引用 ddd 的概念，但是几个概念上明显的错误，facade 模式应该对应的是应用服务层，不管 web 还是 api 只需要通过 facade 接口调用应用就可以了，不需要考虑程序内部实现。防腐层是一个适配器的概念，将外部的感念转变成内部的概念。避免内部业务被外部侵蚀。比如商城项目中，有用户领域，用订单领域，订单中有 buyer，用户中有 user，是两个业务名词，需要用防腐层隔离。
在分包上，每个业务对象都要有对应的测试。说的意思是，这组业务的核心功能和他的测试代码一定要同步进行，不能说，我拿到业务的核心代码，但是没有测试类。还要单独引用一个业务代码测试包才能对这个代码进行检验呢。接口测试代码要在 web,api 层。应该是同步进行的，测试接口不需要考虑应用层的问题。应用服务是 mock 出来的。

阿里的开源连 jar 包自己都管理不好，国内一群还跟风。kpi 的项目吹给领导看的。

多读书，先学 oop，熟练后然后就自己能整理出来领域上下文了。
用自然语言描述清楚你的业务，然后区分出业务名词。
思考业务名词是不是应该建模。
不要去考虑什么微服务。
每个业务名词都清晰了，对象也就丰满了。
用贫血模型永远都是 service 里的大泥球。

朋友 你这个是集成模式 而且测试的方式也有问题

@wangyzj 你这不够深入，不会选沙的也配叫程序员？

socket. io

先说说你们公司用到斐波那契的场景，算法是一个很微观很冷门的技术点，如果你找不到用到斐波那契的业务，那么你为什么问？后端方向很广，算法数据结构都很不实用，没有之一。如果用到算法与数据结构了，有经验的工程师现场学有个半小时一小时也就学会了，直接拿来套业务就可以了，如果你觉得你们业务里需要大量算法应该找一个算法工程师。拿算法来衡量一个程序员是不是眼光太狭隘了？ java 系列非常多的轮子值得学习，那我问一句每出一个轮子学一遍你拿他们当人看吗？
看过源码对贵公司业务有帮助吗？
你让一个人去学习一个生态圈的几百上千人维护的源代码合适吗？
你知道 spring 多少个子项目吗？
学习是应该学习你说的这些东西吗？
其实我理解你，干几年软件开发，写熟练了 curd 不知道学习什么了，然后一头扎进 jvm, 算法，数据结构了，熬几年以大牛姿态来指点江山。我想问问你看过哪个源码？能随便讲讲你认为好的，值得学习的，好在哪里吗？

话说不明白的话，亲，这边建议你不说话哦

没看出你为什么要重构，为什么要模块化，我只能从字里行间看出这个项目的实现和你理解的不一致，然后强迫症发作决定要重构。
下面说说如何重构，讲完之后看你还想不想重构。
找出当前项目里的一个业务点，写测试用例，集成用例，正反测试，保证当前业务不会有一些 bug，保证全绿的情况下可以重构了。用你的实现替换了老的代码测试全通过，再再优化完代码测试通过就可以废弃老的代码了。
当你把所有业务点都经过上面的步骤后你就重构了整个项目。
重构从来不是什么大刀阔斧该架构，重构是抽丝剥茧。
至于你说的是重写项目，不像是重构项目

你能保证自己开发的代码没有 bug 吗，给你找几个人擦屁股还不开心