前提
Controller层提供接口层，用于让外部三方调用
Service层用于做逻辑处理，组装不同业务需要的数据或者操作这些数据，BO是实体数据类也即操作的数据类
Repository：数据存储层，比如数据库
贫血模型
处于贫血模型的架构设计会重Service，轻Bo。因此业务逻辑主要是在Service中做的处理，BO中只是存放数据实体的，数据和逻辑分离，是面向过程开发，对于简单业务来说很好。
充血模型
处于充血模型的架构模式设计来说会重Domain ，轻Service。分离Service的逻辑处理，将涉及数据操作的逻辑放到Domain中抽象出来。Domain和BO的区别主要是BO只有数据，而Domain数据和逻辑处于一块。充血模式适合复杂业务的开发，也即面向对象开发。对于复杂业务来说，逻辑代码会臃肿，将设计数据的操作抽出来利用之后设计，也利于更方便的支持业务。
逻辑解耦，逻辑操作只在Domain中，Service负责访问数据提供数据。将操作数据的职责放到Domain中更容易管理，也更易扩展
精选回答
有些业务逻辑即行为本该属于一个domain，是其一部分，是领域模型驱动而发生的行为，所以也可以称之为领域行为。比如一个人，走路就属于人这个领域模型驱动的行为，是属于人的一部分，而人骑自行车，这个动作就不能归属给人了，自行车也是个领域模型。 而service存在的意义之一就是跨领域模型整合和交互。
只有他能独立完成的事情, 也就是domain object can do的事情放在领域内, 如果不是他可以独立做的事情, 那么不应该放在内部, 应该放在service中, 另外还有数据库访问等, 以及事务等等都应该放在service中, 我理解的领域模型更多的是做的各司其职
个人理解：
可以看到领域内完成的事情是Domain，当一个业务逻辑设计多个领域的时候就需要Service来跨领域去操作不同的Domain了。典型的比如交易信息的记录和充值提现这些虚拟钱包的操作是属于两个领域的。一个是事务记录，一个是余额变化。当需要余额变化的时候记录事务，Service就需要先让余额领域变化，在操作事务领域记录事务。也是所谓的跨领域协作。
开发的过程中也应该去思考哪些操作是一个领域，确定领域的作用和需要的前提条件。Service将数据业务转换成一个个领域模型，去协同不同的领域模型提供对应的前提条件让这些Domain互不干涉，但所需要的条件都是由Sercice去组织
标签：Domain,贫血,Service,模型,充血,领域,逻辑,数据 From： https://blog.51cto.com/u_14689064/5785693