关于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更合理）。

依赖强约束

• app层不能访问infra层，因为它只能看到domain及其中的domainGateway

• adapter可直接访问app层，当然也可通过client层的接口隔离（不强制，但代码结构更清晰）,但不能直接访问infra层。实际当中，实际当中，adapter可能有需要访问domain层的诉求，比如根据外部传入的查询dto在mybatis里拼动态SQL场景，该dto将跨越adapter、app、domain和infra四层，这时，可以考虑在app层做一下XO的转换（例如通过继承、属性复制等手段）。