写在前面前段时间跟领导讨论技术债概念时不可避免地提到了代码的质量，而影响代码质量的因素向来都不是单一的，诸如项目因素、管理因素、技术选型、人员素质等等，因为是技术债务，自然就从技术角度来分析，单纯从技术角度来看代码质量，其实又细分很多原因，如代码设计、代码规范、编程技巧等

1.滥用getter、setter方法在设计实现类的时候，除非真的需要，否则尽量不要给属性定义setter方法。除此之外，尽管getter方法相对setter方法要安全些，但是如果返回的是集合容器，那也要防范集合内部数据被修改的风险。2.Constants类、Utils类的设计问题对于这两种类的设计，我

在领域实体Dao中，实体可以设计为贫血模型和充血模型。贫血模型只包含见到的get和set方法，不包含业务逻辑，是简单的POJO,所有的业务逻辑都放在service层。这种模型并不是面向对象的，和对象相关以来的逻辑被解耦到了业务层，优点是模型很简单，缺点是service层的逻辑负责繁重。充血模型包

 一、贫血模型1.介绍贫血模型是指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在BusinessLogic层。 2.优点各层单向依赖，结构清楚，易于实现和维护。设计简单易行，底层模型非常稳定。3.缺点domainobject的部分比较紧密依赖的持久化domainlogic被分

领域驱动设计，关键是要做领域建模，领域建模的结果叫领域模型。领域模型还有一个名字叫充血模型，以与贫血模型这个名称做对应。贫血领域模型的基本特征是：它第一眼看起来还真

起因昨天群里讨论@北京-sky群主大大，有个问题请教一下，现在项目里看到的分层结构，基本就是controller、service、dao、entity，而service层都很薄，基本就是直接调用dao对表数据进

前提Controller层提供接口层，用于让外部三方调用Service层用于做逻辑处理，组装不同业务需要的数据或者操作这些数据，BO是实体数据类也即操作的数据类Repository：数据存储层，比

DDD实质为充血模型，重点在实体的方法上，先从逻辑上构思该实体可能需要的业务处理(类似面向对象)，service层仅做一些方法的组合贫血模型即是仅定义实体，但是关于实体的业务

贫血模型和充血模型贫血模型充血模型事务脚本模式领域模型模式只包含属性，get和set不仅包含属性，还包含业务逻辑只有状态，没有行为既有状态，也有行为贫

贫血模型一般来说贫血模型：**一个类中只有属性或者成员变量，没有方法**！例如DbFirst从数据库同步实体过来，--对于一个系统刚开始的时候会觉得这时候是最舒服的，但是如