1 分层疑问
无论DDD还是MVC模式构建项目,势必涉及到工程结构的分层,每一层由于定位不同,所以访问的对象也不同,那么对象在每一层传递时就会涉及到对象的转换,这时有人会产生以下疑问:
- 对象种类多,增加理解成本
- 对象之间转换,增加代码成本
- 编写代码时有时不同层对象几乎一样
即使有这样的疑问,我也认为分层是必要的,所以本文我们尝试回答上述疑问。
2 通用分层模型
两种通用模型是MVC和DDD,我之前在文章《DDD理论建模与实现全流程》也详细讨论DDD建模和落地全流程,本文只涉及对象的讨论,所以会对模型有所简化。
2.1 模型分类
- 数据对象:DO(data object)
- 业务对象:BO(business object)
- 视图对象:VO(view object)
- 数据传输对象:DTO(data transfer object)
- 领域对象:DMO(domain object)
- 聚合对象:AGG(aggregation)
2.2 MVC
MVC模型总体分为三层:
- 持久层(persistence)
- 业务层(business)
- 表现层(presentation/client)
每一层使用对象:
- 持久层
- 输入对象:DO
- 输出对象:DO
- 业务层
- 输入对象:BO
- 输出对象:BO
- 表现层
- 输入对象:VO/DTO
- 输出对象:VO/DTO
2.3 DDD
DDD模型总体分为四层:
- 基础设施层(infrastructure)
- 领域层(domain)
- 应用层(application)
- 外部访问层(presentation/client)
每一层使用对象:
- 基础设施层
- 输入对象:DO
- 输出对象:DO
- 领域层
- 输入对象:DMO
- 输出对象:DMO
- 应用层
- 输入对象:AGG
- 输出对象:DTO
- 外部访问层
- 输入对象:VO/DTO
- 输出对象:VO/DTO
3 生活实例
这些对象看起来比较复杂,理解成本很高,好像是为了分层硬造出来的概念。其实不然,这些对象在生活中司空见惯,只不过大家并没有觉察。我们设想有一家三口,小明、小明爸爸和小明妈妈,看看这些对象是怎么应用在生活中的。
3.1 MVC
3.1.1 数据对象(DO)
数据对象作用是直接持久化至数据库,是最本质的一种对象,这就像小明在卧室中穿着背心睡觉,这接近于人最本质的一种状态,小明此时是一种数据对象。
3.1.2 业务对象(BO)
小明起床走出卧室,这时小明就不仅仅是他自己了,他还多了很多身份,例如儿子、学生、足球队队员,不同身份输入和输出信息是不一样的。作为儿子要回应家长的要求,作为学生要回应老师的要求,作为足球队员要回应教练的要求。作为小明从数据对象,在不同的身份场景中变成了不同的业务对象。
3.1.3 视图对象/数据传输对象(VO/DTO)
小明吃完早饭准备去上学,但是嘴角粘上了饭粒,出门前要把饭粒擦掉。数据传输对象需要注意简洁性和安全新,最重要的是只携带必要信息,而不应该携带不必须要信息,所以此时小明变成了视图对象。
3.2 DDD
3.2.1 领域对象(DMO)
领域对象要做到领域完备,从本质上来说与业务对象相同,但是通常使用充血模型,业务对象通常使用贫血模型。
3.2.2 聚合对象(AGG)
学校要开家长会要求小明、小明妈妈和小明爸爸全部参加,其中小明负责大扫除,小明妈妈负责出黑板报,小明爸爸负责教小朋友们踢足球。此时学校和家长联系时是以家庭为单位的,家庭就是聚合对象。
4 一体多面
通过上述实例我们看到,即使是同一个自然人,在不同的场景下也有不同的身份,不同的身份对他的要求是不同的,输入和输出也是不同的。这就是一体多面。
同理对于同一个对象,即使其在数据库只有一条数据,但是由于场景的不同,输入和输出也是不同的,所以有了各种看似复杂的对象。我们再回看上面三个问题,可以尝试给出本文的答案:
对象种类多,增加理解成本:这是必须要付出的成本,小明不能嘴角挂着饭粒去上学
对象之间转换,增加代码成本:这是必须要付出的成本,不同角色切换时必须要付出切换成本,小明不能用回应足球队教练的输出回应老师或者老师,这是截然不同的角色
编写代码时有时不同层对象属性几乎一样:小明作为一个自然人,他自身固有特性也是相同的,所以表现在对象上是很多属性是一致的。但是不同的角色是有不同要求的,所以为了一些细微的差别,也是要新增对象的,这是必要的代价