关于DDD
今天和朋友聊了下DDD,正好我们的系统现在也演化到一定阶段,逻辑越来越复杂,类里行数也在增加,需要找个方法来将逻辑封装好, 之前就了解过一些关于DDD,但不是很明白,今天貌似也领悟到一些,顺便记录一下,系统很小的时候,一些简单的逻辑可以放到几个类就可以,但是系统越来越复杂,就需要分层和解耦,大致DDD讲的就是如何规划层级.
视图模型
视图模型相当于MVC框架中的VIEW,有自己演化的过程,系统界面逻辑交互,都是在调整相应的视图模型,但是不会影响到其他模型.
领域模型
领域模型是业务逻辑相关的模型,业务逻辑写到领域模型中,但是持久化过程等,不应该参杂到领域模型,业务规则和业务逻辑的改变才需要调整领域模型,而且不影响其他层.
数据模型
数据模型只负责数据的承载这一个职责,没有其他的职责,简单的getter setter.
service服务
不属于domain的逻辑,但是又是需要安排domain,比如验证,日志逻辑,放入到service,持久化逻辑(也可以算一个独立的领域,只不过是持久化领域)加入到Repository(Dao),service依赖领域模型和Repository,entity,并对领域模型持久化,涉及到持久化entity的过程都加入到repository(dao),涉及到持久化domain的,就放到service
总结
- 系统结构不是一成不变,需要进化,逻辑就需要找到安放的地方,就需要分层和解耦,需要能独立演化,灵活设计.
- 对于哪部分逻辑是在service,哪部分逻辑是在领域模型,这里要注意,如果领域模型的业务逻辑扩散到service,就会产生严重的耦合,service只负责安排domain,repository,不越权控制domain,domain也不应该含有service的逻辑.
- 面向对象的系统,对象是天然的存在,并不是根据需要才有对象,对象一旦定型,就不能对其内部修改破坏(开闭原则),而要演化出更高层的对象,就要组合其他的对象,而不是直接修改对象内部的固有逻辑,对象的设计必须是圆润的.
- 单一原则:对象只负责一种职责,上帝类虽然复杂,但是太过僵硬,无法被组合,等于废弃.