写点什么

DDD 实战:从需求到代码实现生鲜电商系统 (1)

作者:深清秋
  • 2022 年 2 月 20 日
  • 本文字数:4506 字

    阅读完需:约 15 分钟

DDD实战:从需求到代码实现生鲜电商系统(1)

缘起


开始之前,我想说的是:感谢您在百忙之中,还有兴趣看一位老程序员的分享,尤其是还有点唠叨!


近几年随着云原生技术的发展,微服务如何拆分的问题,越来越成为企业应用架构设计中最为重要的设计决策之一。我在实际工作中,时常碰到客户提出的疑惑:微服务到底要“微”到什么程度才算好?用了微服务架构后,真的能减少业务模块之间的相互耦合、进而提高系统整体可用性吗?为什么我们拆了微服务后,系统反而不如之前的单体应用稳定?不但如此,拆了微服务后,每次需求变更比以前更复杂,不可预测的连带 BUG 持续出现......等等等等。


基于这样的客户诉求,我开始学习 DDD 设计方法。但随着学习的深入,越来越发现软件开发团队要落实 DDD 设计方法并不是一件容易的事。DDD 方法鼻祖 Eric 的经典著作《领域驱动设计 软件核心复杂性应对之道》、以及 Vaughn 的《实现领域驱动设计》都写得比较抽象,很难落地实施。DDD 的难落地程度,导致了程序员圈子甚至出现了一种看法:本来会写代码的,学了 DDD 后反而不会写代码了——也就是俗称的“学废了”。


为了能够让软件开发团队切实的落实 DDD,我决定自己亲身实践一次用 DDD 设计开发一个实际运行的系统,以便于在实际开发过程中积累相关的经验,进而能够将来指导开发团队落地 DDD 方法。很显然的,该实例系统要求既不能太简单以至于没有参考价值、也不能太庞大以至于我一个人在最多半年的业余时间内都搞不定。为此,我选择了本人之前做的一个“群买菜”生鲜电商小程序(你可以从微信小程序搜索到它)系统作为本专题的样例。因为该小程序的产品设计也是本人做的,所以比较熟悉也比较容易操刀。而且该系统也在实际应用过程中,也发现时不时的有业务需求变更,往往因为因为当时没有做架构设计、直接就开始事务脚本性质的编码(在本专题后面章节将会看到),所以导致变更需求也非常困难。为此,于公于私,我都应该将“群买菜”用 DDD 方法重构一遍设计。


在实际开始之前,正好我也看了张逸老师的一本书《解构领域驱动设计》。在该书中,张逸老师体系化的将自己理解的 DDD 很多方法和实践进行了梳理,并给出了自己的一套标准工作流程——DDDUP(领域驱动设计统一过程)。因此,在本专题后续的内容中,我将主要基于张逸老师的 DDDUP 来进行操作。在这里,对张逸老师致以深深的感谢!


同时,因为“群买菜”实际上还是一个相对比较大的系统,且 DDD 其实主要适用于大型软件应用系统的开发,所以我也引入了 scrum 敏捷开发过程,对整个“群买菜”系统分为 5~6 个 sprint(冲刺)来执行。


本质上,这个专题是我个人在实践 DDD 过程中的一些提炼和分享,不能算是培训教材,也不能算是专家经验,只能说是一个热爱分享的程序员对这个世界的输出吧!大家也不要当做这个专题为学习,而当做和我一起经历一次完整的 DDD 需求分析、架构设计、编码实现的旅程吧!


目标读者和预期收获


本专题的目标读者,主要是提升自己在应用软件架构设计方面能力的熟练程序员、开发组长、技术经理等。作为熟练的程序员,你应该已经满足以下列出来的一些要求:

  • 精通 java 开发,尤其需要熟悉 spring-boot 的开发;

  • 精通 1~2 个以上关系数据库和非关系数据库技术,如:mysql/oracle、redis/mongodb 等;

  • 有过 3 年以上应用软件的实际 coding 经验、有过带领 3 人以上程序员小组的开发经验;

  • 对常见的设计模式比较熟悉,在实际项目的 coding 中 ,至少熟练使用过 3 种以上设计模式;

  • 对架构分析模式有所了解,在实际需求分析中,至少使用过 1 种以上分析模式;

  • 最后一条,也是最关键的,作为工程师,对学习新技术新方法有足够的动力,认可“加班就应该加在提升自身的稀缺性上”(这个理念来自于刘润老师)的理念,迫切希望成为架构师、或更优秀的架构师,有志于朝着技术线的资深专家(非管理线)发展;


下面说明经历本专题旅程后,您能得到什么。准确来说,我祝愿您能获得如下的收获:


  • 能够理解 DDD 从需求分析、到架构设计、到编码实现的整个过程,以及其中的工作方法和实用技巧。我们这里所说的“理解”,指的是你能够在自己的团队内部分享、培训、甚至引导团队在项目中使用 DDD。

  • 本专题还将实实在在建立一个全开源的“群买菜”生鲜电商系统,这个电商系统你将可以通过 github 或 gitee 获得全部源代码。你可以将这些源代码用于自己的任何用途,只需要遵守 Apache 开源许可证协议即可。


注(内容会随着专题进展而逐步完善):

DDD 能解决什么,不能解决什么?


根据我个人的项目经验、以及实际做 DDD 设计编码的感受,如果你在项目中遇到下面这 3 种情况,就考虑可以试试用 DDD 来解决问题了:


  • 频繁的业务需求变更导致对系统稳定性的影响不可控。需求修改频繁,而感觉每次修改涉及的范围千头万绪,不透明、不可控,经常因为需求给原来的功能带来不可预测的 BUG。这个问题,其实可能代表着两类需求(视软件产品化程度而不同):

  • 对于项目定制化软件,希望随着业务的发展,业务需求变更只会引起可控的、小范围的变更;

  • 对于产品化程度较高的软件,希望随着软件产品的发展,每个产品组件可相对独立的演进;


  • 30 人以上大项目团队职责划分很纠结。项目很大,团队怎么划分,感觉没有科学依据,凭直觉划分后,总发现一些不可控的耦合或重复开发;


  • 微服务怎么切分很纠结。云原生技术的发展,微服务切分的粒度无法把控。太粗没有意义,太细了又导致运维复杂失控;


上面说的 DDD 比较适合解决问题的场景,当然另一面就是 DDD 也有不适合解决的问题场景。我个人总结了一下,觉得下面这些问题是 DDD 不能解决的:


  • DDD 不能帮助团队决策如何更好的技术栈


  • DDD 不能解决系统的性能相关的瓶颈问题;


  • DDD 几乎不涉及前端 UI 的设计方面;


  • DDD 不能帮助产品经理提升产品设计水平(虽然产品经理了解点 DDD 也有帮助),更不能代替产品经理做产品设计。因为产品设计更多是牵涉到心理、商业等非工程化化思维,而 DDD 仅能解决软件在工程化方面的问题;


  • DDD 不会手把手的教你如何提升需求分析相关软技能,包括:如何和客户沟通需求、如何画业务流程图、如何识别业务用例、如何学习新的业务知识等。虽然它确实给出了一套相对有参考价值的“硬性”方法框架,但未给出任何关于个人如何提升这些“软”性技能的实际建议,它假设你自己去建立和发展这些技能;


  • DDD 不会手把手的教你如何提升软件架构设计相关基础知识和软技能,包括:如何区分哪些逻辑应该放前端实现、哪些放后端实现、前端目前主流技术框架有哪些、后端主要开发技术栈有哪些等等。虽然它确实有一套相对有参考价值的“硬性”方法框架,但同样未给出任何关于个人如何提升这些“软性”基础知识的实际建议,它假设你自己去建立和发展这些技能;


  • DDD 不能解决程序员个人自身的代码质量和规范性问题。虽然它确实能够很大程度上解决代码目录结构、模块划分的规范性问题,但解决不了程序员自身编程水平问题;


看我这里的介绍,看起来 DDD 能解决的问题很有限、而不能解决的问题却很多!我想要说的是:“是的,DDD 并不是万能药,几乎不能解决软件项目中遇到的绝大部分问题!”要知道,即使计算机发展到今天、很多冯.诺依曼体系架构下的开发技术已经发展到了极大丰富,但“需求分析、架构设计(往往同时决定了团队结构)、面向对象”这些技能,仍然是程序员圈子的高端技能,一个类似于 DDD 这样的方法体系,能够解答这些高端技能相关的核心问题,已经是很了不起的方法论。


所以说,无论怎样,DDD 都可以说是一个“有点伟大”的软件设计方法论!虽然,网上很多人都在说 DDD 有很多“伪创新”,但无论“伪”不“伪”,DDD 都是随着云原生微服务发展而迅速被重视的、也确实很有帮助的一套方法论。

能用一句话解释 DDD 核心理念吗?


根据我个人对 DDD 方法论的实践,让我最能记住的其核心理念,就两个字:同构!


说到“同构”,这跟我个人经常困惑的一个问题息息相关:既然代码世界是现实世界的一个“虚拟”映射,为什么我们在现实业务中,人们的直觉认识往往觉得某个业务其实没有太大变化,但是到我们的实际代码中,却要引起“伤筋动骨”甚至“开天辟地”般的变化呢?最后导致新需求的实现,要么被扭曲了不伦不类、甚至放弃业务需求,要么就付出巨大的建设成本、难以忍受的建设周期呢?


我个人理解,这其实是因为我们用代码实现的“虚拟世界”、跟真实业务的“现实世界”不“同构”导致的。说的粗俗一点,就是可能我们真实世界是“六边形”的,但被我们的软件团队映射成了“三角形”的“虚拟世界”,也就是产生了所谓的“异构映射”。那这样的“异构映射”是怎样产生的呢?有句话说的很好:正确的过程才能导致正确的结果、错误的过程一定导致错误的结果。这其实就是我们的软件需求分析师、架构设计师、程序员合起来对现实业务的“解构”错误导致的!


DDD 的核心理念,其实就是试图给出一套方法框架,告诉我们的需求分析师、架构设计师、程序员怎么去尽最大可能的将“真实物理世界”同构化映射为“虚拟代码世界”

本专题解答什么?


说了这么多,我想你可能会问:如果我决定开始学习 DDD,你废话这么多的这个专题,到底能解答我哪些问题?


我想,我试图在这个专题中,回答下列的问题:


  1. DDD 方法论下的软件工程完整视角是怎样的?我会回答这个问题,并且告诉你:有这样的完整工程视角,并且也并不是那么难以理解!虽然 Eric 和 Vaughn 没有给出一个完整的、可操作的软件工程框架,但我试图在“群买菜”这个软件的实现过程中,向你展示这个视角。这里特别强调一下:其实这个视角是张逸老师给的,我可能只是做了一些我自己认为有益的简化。

  2. 在这个软件工程视角里,我需要怎样一步一步来分析、设计、编码、测试软件?我也会回答这个问题,我会通过“群买菜”这个软件的一步一步的工作开展,来向你展示如何在每一步里来做、以及每一步我采用的方法、技巧和思考。

  3. DDD 社区目前的最新发展情况。DDD 可以说目前还在逐步完善中,社区最新有哪些问题的争论、大师们又是怎样的观点?我本人其实对这方面的问题也很感兴趣,我会在编写本专题的过程中,一遍学习一遍和大家分享我个人的理解和体会。

本专题编写风格


为了方便你评估本专题是否值得继续看下去,我这里澄清下自己的编写风格,以供你选择是否继续——当然,如果你继续赏光阅读我下面的内容,我会非常感谢!也非常乐于随时与您交流你发现的我的错误、或其它任何您觉得需要讨论的问题。


  • 我会尽可能的将理论体系浓缩和简化

  • 我会结合实际软件实际案例(并且该软件的开源代码实现一定是可运行的),在案例中贯穿 DDD 相关的方法、原则和技巧,而几乎很少大篇幅的介绍理论本身;

  • 我可能会写得比较啰嗦,尤其是一些技术实现细节方面比较扣,希望您能够有耐心。因为我自己是个很笨的人,学习一个东西的速度很慢,而且我一向希望自己能够“但求甚解”,而不是“不求甚解”。我个人一直秉承“慢就是快”的理念,所以还请您稍微忍受这一点;

  • 我会每周更新一篇,整个专题可能会有 20~30 篇。除了第一篇的大量没有太多技术含量的“废话”外,后面的每一篇,可能需要您每周花费 10 小时左右去阅读和理解。所以,还是上一句话说的:需要您有点耐心;

发布于: 刚刚阅读数: 2
用户头像

深清秋

关注

从菜鸟向大神攀登。。。 2020.11.15 加入

21年IT从业经验,热爱写代码、软件架构设计、软件产品设计。最近决定把自己的一些代码或设计经验分享出来,希望对大家有用!个人秉承职业理念:自己给自己加班,提升自己的稀缺性,其实所有人都可以突破年龄障碍!

评论

发布
暂无评论
DDD实战:从需求到代码实现生鲜电商系统(1)