第一篇

就我们团队目前的代码质量，基本上就跟文章的描述是一致的，可阅读性差，可维护度低，新人上手困难。可以考虑根据这一方面去进行重构。

参数校验和逻辑聚合都是文章描述的一个好思路，团队也开始向这个方面开始转变了。

第二篇

第二篇总体下来还是第一篇的一个深入介绍，主要描述了目前Java环境中如何去实施文章中描述的这部分。

第三篇

第三篇是最有意思的，在我们团队而言，目前绝大多数开发都是面向数据库开发，面向SQL开发的，在过需求的时候我们大脑就已经开始条件反射的去思索应该建立什么样的表结构，需要多少个表，表于表之间的关联关系。

更夸张一点，一次需求过下来，脑子里边已经把表结构给描绘清楚了，接下来只要使用Mybatis插件生成代码，一把梭哈了。

这样下来的缺点就是我们全程都在面向数据库开发，业务都聚焦到数据库中的表结构去了。在某种情形上束缚了我们对于业务本身的思考。

这篇文章给我的感想就是不要去面向数据库开发，而是要面向实体开发，实体是真实世界中业务的一个抽象，这样面向真实世界的业务，才能不被数据库中的增删改查所约束，才能打破这一层的束缚。

实体是数据库表结构的超集，简单业务的实体可能就等同于数据库表结构，复杂业务的实体可能是多个数据库表结构的一个综合体现。