老李一直怀疑自己是不是年纪大了,脑子跟不上了。 作为十几年经验的资深 Java 工程师,维护这公司产品的核心代码的他,现在迭代产品的时候,经常出 Bug 。 有时修复一个 Bug 时间,比开发一个需求的时间要长很多,这是常有的事儿,更可怕的是,改完一个 Bug ,又多出来几个 Bug,让人吐血不止。 这样的情况不在少数,近几次的更新都没有按原计划的时间完成,不但让 Leader 对老李的能力产生怀疑,也让他自己开始怀疑自己。 这是产品迭代到一定时期,必然出现的问题;还是自己年纪大了,在开发时各种问题没有考虑周全,多年的开发经验都不能支撑新的需求。 中年危机加上职业瓶颈,老王觉得自己应该回家修整一下状态了...... 废话,改 Bug 的痛苦,每个人都经历过…...改不完的 Bug,是「思想错误」当你遇到,你应该怎样解决? 面对这一系列让软件陷入无底泥潭的问题,基于面向对象思想的领域驱动设计方法是一个很好的解决方法。 从事过系统设计的富有经验的设计师们,对职责单一原则、信息专家、充血/贫血模型、模型驱动设计这些名词或概念应该不会感到陌生。 我们可以发现领域驱动设计的一大优点:系统高度模块化,代码重用度高,不会出现太多的重复逻辑。 从战略到战术,领域驱动设计(Domain Driven Design,DDD)给出了诸多关于软件架构、设计、建模与编码的方法和模式,以用于应对业务复杂度。 对于学习 DDD 的开发人员而言,第一重要的不是掌握 DDD 的模式,而是要改变分析思维与设计思维的方式。将这种思维方式运用到软件项目开发过程中,就是我所提到的「领域模型驱动设计」,它的核心内容可以通过层层推进的形式汇集为如下三句话:
如何理解这三句话? 当你开始领域模型驱动设计时,必须在分析建模阶段抛开实现技术对你的影响,与需求分析人员、测试人员一起单纯针对「领域」进行分析建模,即提炼与抽象领域概念,并以统一语言和模型的形式来表达。 在设计建模阶段,围绕着一个完整的「场景」开展设计工作。需求分析人员为「场景」编写用户故事;测试人员为「场景」编写验收标准;开发人员则开始解剖「场景」,将其分解为组合任务与原子任务,然后各自分配给不同的角色构造型。 到了实现建模阶段,就针对这些任务定义测试用例,开始测试驱动开发,由内至外到达应用服务时,再将它们集成起来。显然,领域模型驱动设计就是针对领域开展的「合而分分而合」的解构过程。 同时,必须谨记:领域模型驱动设计的基础是限界上下文。在领域驱动设计的战略阶段,同样是一个「合而分分而合」的解构过程:将领域分解为限界上下文,再通过上下文映射联合限界上下文共同实现多个领域场景。 以上内容正是我言犹未尽想要表达的精髓。学习领域驱动设计,就需要抓住 DDD 的根本和精髓。你需要理解什么是限界上下文,它带来的价值是什么;你需要理解如何进行领域建模,统一语言在其中扮演了什么样的角色;你需要理解为何领域驱动设计提倡以领域为驱动力,为何需要领域专家参与到项目开发中来。 提升了对这些内容的认识后,再去学习 DDD 给出的设计模式,学习我给出的固化设计过程,如场景驱动设计。然后找三两个不曾实施 DDD 的项目,寻两三个实施了 DDD 的项目,相互对比其模型与代码,你绝对会有一种醍醐灌顶的感觉。当然,这些都需要你沉下心来细心体会,认真思考,还需要你广泛涉猎更多软件设计与开发的知识,如此方能打通 DDD 的任督二脉。 DDD 不是一门容易衰亡的软件方法学,反而越来越被行业所认可,薪资待遇也是水涨船高超过了大部分平均值。我从 2017 年 11 月写下本专栏的第一个字到现在完成整个专栏,已有两年多的时间了,好在 DDD 在这两年后依然算是一门显学,在微服务与中台光芒的映衬下,DDD 也变得越来越耀眼。 如今,专栏终于完成了!《战略篇》一共 34 章,15 万 5 千字;《战术篇》一共 71 章,35 万 1 千字;合计 105 章,共 50 万 6 千余字,加上两篇开篇词与这篇可以称为写后感的后记,共 108 章,算是凑齐了一百单八将。如此成果也足可慰藉我为之付出的两年多艰辛时光! 如果你想从此写代码再也碰不到 Bug |
|