领域驱动设计,DDD模式有什么好处?

 领域驱动设计的背后,需要开发者不能只专注于眼前功能的实现,而应该能够从全局去了解业务,并充分的将业务吃透,以可传承的知识的形式融入到开发过程中,只有这样才能促进产品更好的开发。

01

传统项目管理模式,让设计成为累赘

作为一名资深软件行业从业者,我以前一直从事项目开发。在项目执行过程中,往往会采用快速开发模式,按照软件工程的基本流程建立一套项目软件管理模式。这个流程大概是这样的:1,需求调研:大概花费合同周期的六分之一时间来进行需求调研,需求调研环节力求对用户需求进行全面的掌握,并整理成需求规格说明书。2,总体设计和详细设计:花合同周期六分之一的时间进行项目的总体设计和详细设计,详细设计必须覆盖所有需求,甚至需要精确到伪代码的编写。3.项目部署:剩下的时间进行项目的现场实施工作。项目的周期和项目的范围往往各不相同,为了保证软件的质量,上述每一个环节都非常重要,哪个环节的缺少都会对项目完成无法弥补的困难。

有时候,有的软件公司往往为了更快的完成项目,会把软件设计人员和开发人员分成两支不同的组织,一支专门进行软件的设计工作,完成甲项目设计后就快速的投入到乙项目的设计过程中。而研发任务留给研发团队来完成,如果遇到设计上的问题,再由设计团队对软件设计进行调整,由开发团队进行实现上的完善。某种意义上讲,这种模式已经成为软件工业上的主流模式,无数家软件公司正是靠这种方式实现了一个又一个的复杂项目的。

然而,这种模式并非完美无缺,他也造成了一系列问题,尤其是单纯从设计角度来说。例如,由于过份的重视设计,每个开发者只能从某个细节入手进行代码的实现,而可能不知道这个功能在整体项目中的位置,缺乏了对项目的整体思维。例如,由于设计人员本身知识面也好,技能也好,可能导致设计出来的成品根本不符合需求,后期需要花大把的时间进行调整,最终导致设计文档成为没用的负担。

02

敏捷开发,解放生产力,从抛弃文档开始

大型软件公司优先意识到这个问题,并对这个模式进行了深入研究,推出了新的理念,极限编程和敏捷开发。在敏捷开发模式中,1,首先要求要抛弃臃肿文档。2,冲刺,以一段时间作为一次冲刺,例如,以两周为一次迭代周期,发一次版本。3,建立里程碑。4,使用看板。5,建立用户故事和统一建模语言来表达一个项目。6,项目组的每一个成员都是团队不可或缺的部分,尽可能的在一个地方办公。7,每天一次例行站立会议。由于敏捷开发极限编程解决了许多现实问题,成为大家广泛使用的行业标准。

互联网公司将敏捷开发用到了极致,然后建立了一套自己的产品发布流程。这个流程有可能是以两周为一次迭代;产品开发周期为五个步骤,需求,原型设计,界面设计,功能开发,测试,发布;使用看板和站立会议,确保任务良好的执行。等等。

 对于互联网公司而言,时间就是生命,谁最先开发出优秀的产品,意味着最先抢占先机。从单纯的功能角度来看,互联网公司的产品往往功能点数量并不会很多,因此在短时间内会把每个功能做到极致。一方面,从需求层面来说,要做到满足百分之八十用户的普遍需求,要细化和固化需求,原型设计力求完美,界面设计力求精确到像素点,文案要经得起考验。功能开发层面,选择最成熟的技术方案,做最稳定的功能,确保更高的质量和更稳定的性能。由于前期准备工作充分,在研发阶段的工作量实际上已经越来越少了。于是,开发阶段的冲刺也意味着更侧重于单纯的应用实现,不再需要写方案,画流程,设计数据库,最后才实现功能。     

03

领域驱动,让程序员心中有码,一剂良方?

     从上述过程可以看出来,现有的产品研发模式,实际上已经抛弃了研发设计过程,而更专注于功能实现,开发者的唯一目标就是最快的时间完成任务,不需要太多的想法,不需要过度的设计,纯粹的功能实现而已。问题是,功能设计真的可以丢弃吗?

    在互联网公司飞速发展的背后,往往需要更加职能化,专业化的团队,产品开发的背后,实际上是分工明确小团队集体智慧的结晶。但是,由于缺失了研发设计环节,就可能导致研发过程中,功能的开发全凭开发者的个人经验。对于简单的业务,尚且能够掌控,稍微复杂一点的业务就可能需要付出一定的代价才能勉强应付了。由于功能开发取决于个人经验,就可能导致模块的开发,从短期来看满足了眼前的应用指标,但是却为后期的发展留下了弊端。随着原有开发者工作职责的调整,或者离职,将最终导致凭经验开发的功能模块成为无人能维护的神之领域。

      在这样的背景下,领域驱动设计成为普遍的选择。实施领域驱动,往往需要由领域专家对系统进行分析,将系统抽象化,然后建立相应的领域模型。实际上领域驱动设计,领域建模同样是非常重要的部分。即团队应使用统一的语言建立软件领域模型,并根据模型来指导开发,其模型应该是能够自我解释,让人通过模型可以理解开发者的意图。通过领域驱动设计,让不同的开发者根据应用场景进行模型设计之后,再按照一致性的规范实现功能,最终可以有效的保证产品研发质量的提升。领域驱动设计的背后,需要开发者不能只专注于眼前功能的实现,而应该能够从全局去了解业务,并充分的将业务吃透,以可传承的知识的形式融入到开发过程中,只有这样才能促进产品更好的开发。然而,领域驱动真的是一剂万能的良方吗?


未经允许不得转载:996ICU » 领域驱动设计,DDD模式有什么好处?

赞 (0) 打赏