前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >领域驱动设计,让程序员心中有码

领域驱动设计,让程序员心中有码

作者头像
MavenTalker
发布2019-07-19 11:03:03
3430
发布2019-07-19 11:03:03
举报
文章被收录于专栏:歪脖贰点零歪脖贰点零
01传统项目管理模式,让设计成为累赘

作为一名资深软件行业从业者,我以前一直从事项目开发。在项目执行过程中,往往会采用快速开发模式,按照软件工程的基本流程建立一套项目软件管理模式。

这个流程大概是这样的:

1,需求调研:大概花费合同周期的六分之一时间来进行需求调研,需求调研环节力求对用户需求进行全面的掌握,并整理成需求规格说明书。 2,总体设计和详细设计:花合同周期六分之一的时间进行项目的总体设计和详细设计,详细设计必须覆盖所有需求,甚至需要精确到伪代码的编写。 3.项目部署:剩下的时间进行项目的现场实施工作。

项目的周期和项目的范围往往各不相同,为了保证软件的质量,上述每一个环节都非常重要,哪个环节的缺少都会对项目完成无法弥补的困难。

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

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


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

大型软件公司优先意识到这个问题,并对这个模式进行了深入研究,推出了新的理念,极限编程和敏捷开发。

在敏捷开发模式中:

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

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

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


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

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

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

在这样的背景下,领域驱动设计成为普遍的选择。实施领域驱动,往往需要由领域专家对系统进行分析,将系统抽象化,然后建立相应的领域模型。实际上领域驱动设计,领域建模同样是非常重要的部分。即团队应使用统一的语言建立软件领域模型,并根据模型来指导开发,其模型应该是能够自我解释,让人通过模型可以理解开发者的意图。通过领域驱动设计,让不同的开发者根据应用场景进行模型设计之后,再按照一致性的规范实现功能,最终可以有效的保证产品研发质量的提升。

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-11-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 MavenTalk 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 02敏捷开发,解放生产力,从抛弃文档开始
  • 03 领域驱动,让程序员心中有码,一剂良方?
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档