关于COLA架构的讨论

理解

分层

概念网上可以搜到很多,大体分为:

adapter

client

app

infra

domain

这五层。

图例这里有,就不贴了。

adapter和app相当于spring里的controller+service,domain是领域模型层,infra相当于domain的实现层(比如dao或rpc访问)。唯独client,有点疑问,目前我在实践中是把client作为app的对外接口层,隔离adapter和app之用。但也看到其他的理解,比如认为client是对外部接口调用的封装(我个人倒认为infra层做这个事情更合适,因为infra是业务防腐层)。

对象:XO

vo(value object):adapter层组装的对象,adapter将app返回的dto处理成可供界面展示的vo。它的重要特点就是展示,所以,一般服务端返回给浏览器或APP展示的数据都是vo,而从浏览器或APP调用服务端rest接口传递的数据则是dto,因为后者往往是内部数据,着重体现了传递(transfer)二字。

dto:app层要处理的对象,在前端 -> adapter -> app层间传递使用,所以叫data transfer object。app层可以将entity组装成dto(这种组装可能是内存里做的,但更一般的是数据库的关联查询语句)。

entity:特定领域的对象模型,放domain层。

do(data object):infra层对象,由infra层将rpc、查数据库获得的do转成entity。这里有个问题,如果在mybatis里做一个关联查询,查询出的其实是一个dto(比如领域模型A里包含了领域模型B),但这个dto是不能放app层的(那样infra无法访问),逻辑上也不建议放infra层,就只能放domain了。

实践当中,有两个极端,一是让vo在各层间传递,实际充当了四类对象,这样的vo很大,填充的字段会越来很多,很难做到内聚和解耦;一是每层都做自己的XO,这样会有很多看起来很相似的数据类,数据类间的converter工作量也很大。

我个人的建议:至少要有entity(关联查询时是dto)和vo这两层对象,确保界面与业务领域的适当解耦,同时数据converter的工作量也可控。当然,如果就是单表的CRUD,仅有一层entity对象也是可以的(实际业务中应该不多见,毕竟界面展示通常要考虑数字转枚举、国际化展示等,新做一层vo更合理)。

你可能感兴趣的:(架构)