微服务架构原理与开发实战_张刚 编著_AZW3_MOBI_EPUB_PDF_电子书(无页码)_张刚 编著

内容节选

7.2领域驱动设计概述 领域驱动设计是十几年前就被提出的软件设计方法,但是一直没有被很好地推广运用,随着微服务的兴起,软件开发者急需一种科学可行的设计方法来实现更好的模型设计和服务划分,而领域驱动设计就是这样一种方法。 7.2.1 DDD的概念 领域驱动设计的英文为Domain Driven Design,简称DDD。早在2003年埃里克·埃文斯(Eric Evans)就提出了领域驱动设计的主要概念,并指出领域驱动设计是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法,虽与技术无关,但并非对技术不关心。 在十几年前,我们对软件的理解和包括软件自身的发展都没有达到今天的水平,开发者也没有遇到今天复杂的场景,导致DDD的应用并不广泛,直到互联网的浪潮掀起了软件技术的变革,微服务的兴起直接带动了领域驱动设计的影响力,人们发现领域驱动设计就是为微服务而生的,这也是笔者在本书中介绍DDD的原因。 领域驱动设计是一种方法理论,可以理解为一种工具,一种更加重视业务的核心价值,注重领域专家参加软件开发设计过程,将复杂的设计放在有限界的模型上,不断迭代、完善概念,解决特定领域问题的工具,其重点如图7.2所示。 图7.2 领域驱动设计重点 为了创建好的软件,我们必须知道该软件的用途。例如,若想开发一套城市一卡通系统,就必须先了解一卡通的业务领域,否则无法完成一卡通的软件系统。所以,领域驱动设计更加注重领域专家与技术团队的合作。 开发具有真正业务价值的软件并不容易,通常企业无论大小都有自己的核心战略,而软件契合核心业务,展现出核心价值,就是一个成功的软件,领域驱动设计就能够更好地帮助我们聚焦于业务价值,清楚地划分不同系统和业务的关注点,使系统拥有战略设计的方法。 领域专家是指在特定领域或主题中具有权威的人,通常是产品需求方、系统使用者、销售或设计师,可以是决定项目的甲方领导,也可能是一线普通员工,但都有一个共同点,就是不了解技术,但很懂业务。那么,在领域驱动设计的实施中,我们将这些不懂技术的人引入团队,学习他们的领域知识,并帮助他们理解模型设计和系统的行为。 限界上下文是领域驱动设计的一种核心的实现模式,是应用和模型的边界,并明确限界上下文之间的关系,能够帮助我们更加清晰地定义出领域模型的职责,如图7.3所示,这在后面的章节会详细介绍。 图7.3 限界上下文示意图 总体而言,领域驱动设计是软件核心复杂性的应对之道,能帮助我们了解业务领域,划分模型的边界,实现能够体现用户核心价值的软件。 7.2.2 DDD解决了什么问题 一个方法必然是为了解决问题而产生的,如果说领域驱动设计是方法论,那么DDD解决了什么问题?换句话说,我们为什么需要DDD?笔者认为,领域驱动设计解决的核心问题有两个:软件无法准确地表达核心的业务价值;复杂类软件的设计在后期难以进行。 DDD能让软件更准确地表达核心的业务价值。很多人说领域驱动设计可以让领域专家和开发人员工作在一起,使团队内部对模型的设计和理解达成统一,这个观点非常重要,与领域专家紧密的合作和沟通确实是领域驱动设计中重要的一环,但合作和沟通并不是一个软件工程的目的,而是手段,目的或成效是帮助软件更准确地表达业务的价值。 在以往的很多项目中,无论是产品经理、业务分析师还是资深的开发者,在实施软件项目时,都会遇到客户反复修改需求,或者在查看软件的阶段性成果后改变设计的情况,不仅令人头疼,而且极端情况下会导致项目失败。造成这个问题的根本原因有两个:一是因为软件项目本身有渐进明细的特点,客户开始也不清楚自己想要什么;二是软件具有一定的领域性,甚至是很冷门的领域,软件的开发者需要重新学习新的领域知识,而这中间会产生理解上的分歧,那么这时让领域专家参与项目的设计阶段就十分必要。当然,设计发生在开发的整个过程中,只有不断参与设计、优化设计、统一认知,才能保证开发出的软件是需求方想要的且最能表现业务价值的。 DDD能指导我们设计出一个更加合理、扩展性更好的系统架构(尤其是在复杂的领域中,软件设计的合理性尤为重要),获得一个更有用的模型,更加清晰和准确的模型边界及更好的用户体验。 有很多项目由于工期或资源的限制,一开始就写代码、堆功能,后期随着需求增多,业务功能越来越复杂,开发人员发现项目越来越难以继续,冲突增加,代码变得难以维护,这时如果要加一个新功能,他们更愿意选择重新开发,因为无论是服务拆分,还是结构重构,都无法改变现状。造成这个问题的原因有很多,如错误的代码实践,糟糕的测试覆盖率,模糊的服务边界,甚至是错误的模型设计,还有,缺少统一的认识,导致设计模型脱离业务的本质,错误定义、重复的定义越来越多,在复杂的需求下,设计变得难以捉摸、无从下手。 领域驱动设计能很好地帮助项目团队解决这些问题,通过它可以在复杂的领域中划分......

  1. 信息
  2. 内容简介
  3. 前言
  4. 第1章 微服务概述
  5. 1.1 微服务的概念
  6. 1.2 微服务与SOA
  7. 1.3 单体式架构
  8. 1.4 微服务架构概述
  9. 1.5 微服务的挑战
  10. 第2章 微服务架构设计
  11. 2.1 微服务架构的难点
  12. 2.2 架构设计
  13. 2.3 微服务的核心组件
  14. 第3章 Spring Cloud相关组件
  15. 3.1 统一配置中心
  16. 3.2 断路器
  17. 3.3 健康监控
  18. 3.4 分布式链路跟踪
  19. 第4章 契约测试
  20. 4.1 契约测试概述
  21. 4.2 契约测试与TDD
  22. 4.3 契约测试与独立交付
  23. 4.4 契约测试的相关技术与用法实战
  24. 第5章 API网关
  25. 5.1 API网关的意义
  26. 5.2 API网关的职责
  27. 5.3 API网关的缺点
  28. 5.4 使用API网关认证身份
  29. 5.5 API网关技术实战
  30. 第6章 BFF用于前端的后端
  31. 6.1 回顾前后端分离发展史
  32. 6.2 BFF诞生
  33. 6.3 基于RESTful的BFF
  34. 6.4 基于GraphQL的BFF
  35. 第7章 领域驱动设计
  36. 7.1 如何划分微服务
  37. 7.2 领域驱动设计概述
  38. 7.3 领域和子域
  39. 7.4 领域事件
  40. 7.5 聚合和聚合根
  41. 7.6 限界上下文
  42. 7.7 六边形架构
  43. 7.8 DDD的挑战
  44. 第8章 Docker和K8s
  45. 8.1 虚拟化技术
  46. 8.2 Docker容器化
  47. 8.3 学习使用Docker
  48. 8.4 容器编排
  49. 8.5 云商的支持
  50. 第9章 持续集成、部署与交付
  51. 9.1 持续集成(CI)
  52. 9.2 持续交付(CD)
  53. 9.3 持续部署(CD)
  54. 9.4 CI/CD工具
  55. 第10章 任务管理
  56. 10.1 任务管理概述
  57. 10.2 实战演练
  58. 第11章 事务管理
  59. 11.1 事务概述
  60. 11.2 CAP理论
  61. 11.3 BASE理论
  62. 11.4 解决方案
  63. 11.5 对账是最后的屏障
  64. 第12章 传统架构的微服务转型之路
  65. 12.1 传统架构转型的难点
  66. 12.2 识别领域与界限
  67. 12.3 分块重构法
  68. 12.4 代理隔离法
  69. 12.5 转型不是一蹴而就的