在 Golang 中尝试简洁架构

fredvence ·
我也有写过类似的项目. 几个问题很纠结: 1) 按领域驱动来说, usecase层代码要真正体现对业务逻辑的表达, 需要通过领域实体对业务进行建模. 那么领域实体, 和仓储层的实体(数据表), 不应该是一个东西. 对于简单业务来说, 领域实体与仓储层的实体 非常类似, 多写一次很麻烦, 对象间赋值也很麻烦. 但是, 对于稍微复杂业务, 共用实体也在实践中导致很多问题, 比如, 实体上不不断的被添加很多扩展的属性(成员). 来表达业务的状态, 或者为了拼凑对象让接口层刚好返回API的需要的数据. 时间一长, 变得混乱. 2) 对于聚合查询, 其实从可以API层, 直接访问仓储层, 跳过usecase层. 3) usecase层, 跟仓储的db对象是解耦的, 那么如何在业务中表达事务? 事务也是业务逻辑的重要组成部分. 我的做法是建立事务的抽象接口. 这是一个重要的问题. 4) api层的独立测试, api层逻辑主要是出入参的校验, 转换, 组装, 写测试用例实际的投入产出比不高. 把api层+usecae层一起测试, 实践中更实用. 所以, 可以不对usecase层做接口定义. 当然, 对多个usecase间有依赖的情况, 没有接口, 难实现usecase的独立测试, 也是个纠结点. 5) 一些动态参数的传递, 比如,列表的查询条件, 其实用map会方便很多. 不论用不用ORM框架, 仓储层都要出现这种逻辑代码, if xx条件有值 then + 'and xx=?' , 最终生成动态的where sql语句. 这种参数个人觉得map比struct方面很多, 当然牺牲参数校验的便利性. 总之, 分层清晰了, 解耦了, 代码就啰嗦了, 写起来就狗屎了. 加个参数, 代码改一大圈.
#3
更多评论
对于新手小白的我来说很有收获,随着技术演变,在一些专有词汇方面也有很多改变,但整体是可以对应起来理解的;例如作者提到的仓库层和用例层,个人理解现在很多在架构设计的时候对应的是 Services 层和 APIS(Controller)层,都同理可解读。
#2