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