课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
领域驱动设计是目前大多数企业都在使用的一种软件开发设计模式,下面我们就通过案例分析来了解一下,领域驱动设计分层结构包含哪些。
当我们完成领域模型构建之后,我们需要先确定下微服务内部的领域分层结构,因为这个领域分层的好坏直接决定了我们微服务的工程结构是否合理,调用逻辑是否清晰。而这些领域模型都需要映射到实际的代码,我们开发的代码到底应该放在哪一层,放在哪些目录中,都需要依托于领域封层的结果。但是真正的领域驱动设计在怎么规范代码结构上面实际也没有具体的规范,因此我们需要根据自己的实践经验以及思考进行划分。
分层的目的实际上就是让各层的逻辑可以分工协作、各司其职,避免不必要的代码互相污染。同时结构清晰的分层结构也比较便于后期的重构以及拆分或者合并,实际上也是一种在为未来可能存在的变化节省研发成本。
这里需要说明的是,在传统的领域分层中,是将基础设施层作为其他三层的依赖的,但是实际上这种方式是有问题的。为什么这么说呢?因为如果我们真的按照用户接口层、应用层以及领域层都依赖基础设施层的话,那基础层就成了核心的层级了,但是实际上领域层才是真正的核心,这显然违背了DDD以领域为核心的设计思想。因此我们使用依赖倒置的方式,让基础设施层去依赖领域层,这样做的好处就是可以让领域层更加的职责单一以及更加的纯粹,他不需要关心数据是怎么来的,无论是数据库查来的还是缓存萃取出来的还是从外部查来的,它只需要关心它自己领域内的业务逻辑就可以。既然我们明确了该怎么进行领域分层,那么各层的数据组织形式是怎样的呢?
各层数据对象
VO(ViewObject,视图对象):该层的视图数据对象主要的作用就是将应用层的数据进行组装后形成用于页面展示的视图数据。
DTO(DataTransferObject,数据传输对象):DTO主要作为Application层的入参和出参,用于用户接口层与应用层之间的数据传输。
Model(领域对象):领域对象是我们正常业务应该用的领域业务模型,它的字段和方法应该和业务语言保持一致,不需要进行持久化和序列化,他主要存在与内存中。也就是说,所以Model和DO可能字段属性都不一样。
DO(DataObjec,数据对象):一般都是使用PO作为持久化的数据对象,但是笔者习惯使用DO,因为我觉得数据对象当然要和数据库中的字段相对应的。因此从名称来说,DO作为持久化对象我想更加合适一点。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。