其实不管是贫血还是充血，业务逻辑都是有的，从面向对象角度，“贫血”下的领域模型bean是个婴儿，会有相应的业务bean来充当父母的角色，来组织业务逻辑；而“充血”下的领域模型bean是婴儿长大成人，力所能及了，不再需要父母帮助。这样看来，其实各有各的道理。
DDD下，相比于传统开发模式，充血模式给实际开发工作带来巨大的变化，哪些逻辑应该放在领域模型bean里面，放在哪个领域模型bean里面；因为逻辑更为收敛，一些细小的改动，影响面更大，影响更深；因此，对代码的把控需求（代码评审）更为重要。
但充血模式，始终还是面向对象的范畴。只不过从某些角度，领域模型看起来更像对象。
DDD推崇六边形模式、洋葱模式，即把描述领域模型的模块放在最核心的位置，其他模块均依赖该模块。学习过很多DDD项目，基本上是逻辑分包来体现依赖关系。其实，对于大型复杂业务系统，直接分子模块，分项目也未尝不可，更利于管控，边界更加清晰，领域模型的代码也更加“纯粹”。
依赖倒置、动态代理 一般用于领域事件、仓库等涉及技术框架或应用逻辑，将具体实现放置实现类，接口类由领域模型模块调用。
一些通用的逻辑也可以封装成动态代理类，避免实现类重复造轮子。
这些措施能够将技术实现屏蔽在领域模型模块之外，也起到“纯粹”代码的作用。
