阅读别人的文章和代码总有一些好的发现。把这些优秀的实践转换成自己的习惯，一点一点的进步！
最近我在做 code review 的时候，发现很多人不会写代码了。公司工作好几年的，代码写的也只是完成了业务需求而已。所以今天抽个时间，总结一点小技巧。
你真的会写 java 吗？
很多人都说会，你看我的写了好多年了。那我换一个方式问你，你真的优秀吗？
我先来讲一个最简单案例：domain 包名。这个案例，我记得《阿里巴巴开发手册》中写的也有。
根据很多java程序员的”经验”来看，一个数据库表则对应着一个 domain 对象，所以很多程序员在写代码时，包名则使用：com.xttblog.domain ，这样写好像已经成为了行业的一种约束，数据库映射对象就应该是 domain。但是你错了，domain 是一个领域对象，往往我们再做传统 java 软件 web 开发中，这些 domain 都是贫血模型，是没有行为的，或是没有足够的领域模型的行为的，所以，以这个理论来讲，这些 domain 都应该是一个普通的 entity 对象，并非领域对象，所以请把包名改为：com.xttblog.entity。
如果你还不理解我说的话，请看一下Vaughn Vernon出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(实现领域驱动设计)这本书，书中讲解了贫血模型与领域模型的区别，相信你会受益匪浅。
现在，我问一下你，你们公司的项目是不是就是这样创建包的？或者曾经工作过的公司是这样创建包的。
包建的不规范就不会写java代码？
好吧，我再说一个例子。
前端请求我们的接口，数据传输我们应该使用 DTO，而你是不是直接就把和数据表对应的实体作为传输对象了。连 DTO 都没有？
只要是用于网络传输的对象，我们都认为他们可以当做是DTO对象，比如电商平台中，用户进行下单，下单后的数据，订单会发到OMS 或者 ERP系统，这些对接的返回值以及入参也叫DTO对象。
另外，在使用 DTO 时，是怎么转换成 entity 的？很多人这样写：
你看吧，你虽然使用了 DTO，但是在转换对象时，还在一个一个的 get/set。
你看看同一个组的同事，都是用了 org.springframework.beans.BeanUtils#copyProperties，你为什么不使用呢？如果有几十个属性，你是不是要 get/set 几十次？
就算使用 get/set 方法进行转换，你也可以追随潮流哈。现在都流行链式写法，类似下面的用法：
其实呢？这里可以使用一个设计模式。Builder模式（建造者模式），这里说一下，关于设计模式，我后台有一套视频教程，公众号内回复：“设计模式”即可免费下载！
类似的神操作还有很多，时间关系，我就不多说了。比如，验证交给前端做，后端没有验证等等，太多了。
