还在搞MVC?DDD才是yyds!

「 关注“石杉的架构笔记”,大厂架构经验倾囊相授 

 儒猿技术团队最新出品

《基于ShardingSphere的分库分表实战》

还在搞MVC?DDD才是yyds!_第1张图片


文章来源:【公众号:Java研发】

DDD 这几年越来越火,资料也很多,大部分的资料都偏向于理论介绍,有给出的代码与传统 MVC 的三层架构差异较大,再加上大量的新概念很容易让初学者望而却步。本文从 MVC 架构角度来讲解如何演进到 DDD 架构。

从 DDD 的角度看 MVC 架构的问题

代码角度:

  • 瘦实体模型:只起到数据类的作用,业务逻辑散落到 service,可维护性越来越差

  • 面向数据库表编程,而非模型编程

  • 实体类之间的关系是复杂的网状结构,成为大泥球,牵一发而动全身,导致不敢轻易改代码

  • service 类承接的所有的业务逻辑,越来越臃肿,很容易出现几千行的 service 类

  • 对外接口直接暴露实体模型,导致不必要开放内部逻辑对外暴露,就算有 DTO 类一般也是实体类的直接 copy

  • 外部依赖层直接从 service 层调用,字段转换、异常处理大量充斥在 service 方法中

项目管理角度:

  • 交付效率:越来越低。

  • 稳定性差:不好测试,代码改动的影响范围不好预估。

  • 理解成本高:新成员介入成本高,长期会导致模块只有一个人最熟悉,离职成本很大。

第一层:初出茅庐

以上的问题越来越严重,很多人开始把眼光转向 DDD,于是埋头啃了几本大部头的书,对以下概念有了基本的了解:

  • 统一语言

  • 限界上下文

  • 领域、子域、支撑域

  • 聚合、实体、值对象

  • 分层:用户接口层、应用层、领域层、基础层

于是把 MVC 架构进行了改造,演进成 DDD 的分层架构。

DDD 分层架构:

还在搞MVC?DDD才是yyds!_第2张图片

MVC 架构到 DDD 分层架构的映射:

还在搞MVC?DDD才是yyds!_第3张图片

至此,算了基本入门了 DDD 架构,扩展性也得到了一定的提升。

不过随着业务的发展,不断冒出新的问题:

  • 一段业务逻辑代码,到底应该放到应用层还是领域层?

  • 领域服务当成原来的 MVC 中的 service 层,随着业务不断发展,类也在不断膨胀,好像还是老样子啊?

  • 聚合包含多个实体类,这个接口用不到这么多实体,为了性能还是直接写个 SQL 返回必要的操作吧,不过这样貌似又回到了 MVC 模式。

  • 既然实体类可以包含业务逻辑、领域服务也可以放业务逻辑,那到底放哪里?

  • 资料上说领域层不能有外部依赖,要做到 100% 单测覆盖,可是我的领域服务中需要用到外部接口、中央缓存等等,那这不就有了外部依赖了吗?

第二层:草船借箭(战术设计)

带着问题不断学习他人经验,并不断的尝试,逐渐 get 到以下技能:

| 领域层

领域(domain)是个模块,包含以下组成部分,传统的 service 按功能可能拆分到任何一个地方,各司其职:

  • 1 个聚合

  • 1 到多个实体

  • 若干值对象

  • 多个 DomainService

  • 1 个 Factory:新建聚合

  • 1 个 Repository:聚合仓储服务

聚合根(AggregateRoot):聚合本身也是一个实体,聚合可以包含其他实体,其他实体不能脱离聚合而单独提供服务,比如一篇文章下的评论,评论必须从属于文章,没有文章也就没有评论。仓库层(repository)也必须是以聚合为核心提供服务的。

实体可以理解为一张数据库表,必须有主键。值对象没有主键,依附于实体而存在,比如用户实体下住址对象,一般在数据库中已 json 字符串的形式存在;最常见的值对象是枚举。

仓库服务(repository):资源库是聚合的仓储机制,外部世界通过资源库,而且只能通过资源库来完成对聚合的访问。资源库以聚合的整体管理对象。

因此,一个聚合只能有一个资源库对象,那就是以聚合根命名的资源库。除此之外的其他对象,都不应该提供资源库对象。仓储服务的实现一般有 Spring Data JPA、Mybatis 两种方式。

如果是用 Spring Data JPA 实现,直接使用 JPA 注解 @OneToOne、@OneToMany,配合 fetch 配置,即可一个方法查询出所有的关联实体。

如果是用 Mybatis 实现,那么 repository 需要加入多个 mapper 的引用,再手动做拼装。

这里有一个经典的 Hibernate 笛卡尔积问题,答案是在聚合根中,一般不会加在大量的关联实体对象。如果确实需要查询关联对象而关联对象又比较多怎么办呢?

在 DDD 中有一个 CQRS(Command-Query Responsibility Segregation)模式,是一种读写分离模式,在此场景中需要将查询操作放到查询命令中分页查询。

当然 CQRS 也是一个很复杂模式,不应照搬他人方案,而是根据自己的业务场景选择适合自己的方案。

以下列举了 CQRS 的几种应用模式:

还在搞MVC?DDD才是yyds!_第4张图片

工厂服务(factory):作用是创建聚合,只传入必要的参数,工厂服务内部隐藏复杂的创建逻辑。简单的聚合可以直接通过 new、静态方法等创建,不是必须由 factory 创建。

领域服务:单个实体对象能处理的逻辑放到实体里,多个实体或有交互的场景放到领域服务里。

领域服务可不可以调用仓储层或外部接口?可以,但不能直接和领域服务代码放一起,领域服务模块存放 API,实现放基础层(infrastructure)。

领域服务对象不建议直接以聚合名+DomainService 命名,而要以操作命令关联,比如用户保存服务命名为:UserSaveService,审核服务:UserAuditSerivce。

| 应用层

应用层通过应用服务接口来暴露系统的全部功能。在应用服务的实现中,它负责编排和转发,它将要实现的功能委托给一个或多个领域对象来实现,它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式,它隐藏了领域层的复杂性及其内部实现机制。

比如下订单服务的方法:

public void submitOrder(Long orderId) {
    Order order = OrderFetchService.fetchById(orderId);   //获取订单对象
    OrderCheckSerivce.check(order);    //验证订单是否有效
    OrderSubmitSerivce.submit(order);  //提交订单
    ShoppingCartClearService.clear(order);  //移除购物车中已购商品
    NotifySerivce.emailNotify(order.getUser());  //发送邮件通知买家
}

对于复杂的业务来说,应用层也有几种模式:

  • 编排服务:最典型比如 Drools

  • Command、Query 命令模式

  • 业务按 Rhase、Step 逐层拆分模式

还在搞MVC?DDD才是yyds!_第5张图片

| Maven 模块划分

基础层是比较简单一层,不过这里还有个比较疑惑的问题:按照 DDD 的四层架构图去划分 Maven 模块,基础层是最上的一层,但是基础层也要包含基础组件供其他层使用,这时基础层应该是放到最下层,直接按照这样构建 Maven 模块会造成循环依赖。

还在搞MVC?DDD才是yyds!_第6张图片

相比来说,另一个架构图更准确一些,不过依然没有直观体现 Maven 模块如何划分。

还在搞MVC?DDD才是yyds!_第7张图片

我的最佳实践是将基础层拆分两部分,一部分是基础的组件+仓储 API,一部分是实现。

maven 模块划分图如下所示:

还在搞MVC?DDD才是yyds!_第8张图片

第三层:运筹帷幄(战略设计)

经过以上的两层的磨炼,恭喜你把 DDD 战术都学习完了,应付日常的代码开发也够了,不过作为架构师来说,探索的道路还不能止步于此,接下来会 DDD 战略部分。

战略部分关注点有 3 个:

| 统一语言

统一语言的重要性可以根据 Jeff Patton 在《用户故事地图》中给出的一副漫画来直观的描述:

还在搞MVC?DDD才是yyds!_第9张图片

统一语言是提炼领域知识的输出结果,也是进行后续需求迭代及重构的基础,统一语言的建立有以下几个要点:

  • 统一语言必须以文档的形式提供出来,并且在整个项目组的各团队达成共识。

  • 统一语言必须每个中文名有对应的英文名,并且在整个技术栈保持一致。

  • 统一语言必须是完整的,包含以下要素:领域模型的概念与逻辑;界限上下文(Bounded Context);系统隐喻;职责的分层;模式(patterns)与惯用法。

| 领域划分

以事件风暴的形式(Event Storming),列出所有的用户故事(Use Story),用户故事可通过 6W 模型来构建,即描写场景的 Who、What、Why、Where、When 与 How 六个要素。

然后圈选功能相近的部分,就形成了领域,领域又根据职能不同划分为:核心域、支撑域、通用域。

具体的过程有很多参考资料,这里不再细讲,最终的输出是领域划分图,以下是一个保险业务示例:

还在搞MVC?DDD才是yyds!_第10张图片

| 限界上下文

限界上下文包含两部分:上下文(Context)是业务目标,限界(Bounded)则是保护和隔离上下文的边界。

比如上图中的实现部分即是限界上下文的边界,虚线部分代表了领域的边界。限界上下文没有统一的划分标准,需要的读者根据自己的业务场景来甄别如何划分。

一个上下文中包含了相同的领域知识,角色在上下文中完成动作目标。

边界体现在以下几方面:

  • 领域逻辑层:确定了领域模型的业务边界,维护了模型的完整性与一致性,从而降低系统的业务复杂度。

  • 团队合作层:限界上下文一般也是用户换分团队的依据。

  • 技术实现层:限界上下文可当成是微服务的划分边界。

DDD 的不足

DDD 架构作为一套先进的方法论,在很多场景能发挥很大价值,但是 DDD 也不是银弹。高级的架构师把 DDD 架构当成一种工具,结合其他架构经验一起为业务服务。

DDD 的不足有几个方面:

  • 性能:DDD 是基于聚合来组织代码,对于高性能场景下,加载聚合中大量的无用字段会严重影响性能,比如报表场景中,直接写 SQL 会更简单直接。

  • 事务:DDD 中的事务被限定在限界上下文中,跨多个限界上下文的场景需要开发者额外考虑分布式事务问题。

  • 难度系数高,推广成本大:DDD 项目需要领域专家专家,且需要特别熟悉业务、建模、OOP,对于管理者来说评估一个人是否真的能胜任也是一件困难的事情。

总结

本文从 MVC 架构开始讲述了如何从演进到 DDD 架构,限于篇幅很多 DDD 的知识点没有讲到,希望大家在实践过程中能灵活运用,尽享 DDD 给业务带来的价值。本文如有不足之处敬请反馈。

-------------  END  -------------

帮您解忧,儒猿特别打造 “跳槽训练专栏系列”

内容试看(点击)   |    课程目录(点击)

还在搞MVC?DDD才是yyds!_第11张图片

还在搞MVC?DDD才是yyds!_第12张图片

还在搞MVC?DDD才是yyds!_第13张图片

<<  滑动查看更多专栏  >>

40b47348b09f6ddd28335f1fbcb669cd.png

点个在看你最好看

cf3e0b088ec6eadd161c6e09a07ac9b3.png

你可能感兴趣的:(大数据,编程语言,java,人工智能,python)