传统项目管理模式，让设计成为累赘
作为一名资深软件行业从业者，我以前一直从事项目开发。在项目执行过程中，往往会采用快速开发模式，按照软件工程的基本流程建立一套项目软件管理模式。这个流程大概是这样的：1，需求调研：大概花费合同周期的六分之一时间来进行需求调研，需求调研环节力求对用户需求进行全面的掌握，并整理成需求规格说明书。2，总体设计和详细设计：花合同周期六分之一的时间进行项目的总体设计和详细设计，详细设计必须覆盖所有需求，甚至需要精确到伪代码的编写。3.项目部署：剩下的时间进行项目的现场实施工作。项目的周期和项目的范围往往各不相同，为了保证软件的质量，上述每一个环节都非常重要，哪个环节的缺少都会对项目完成无法弥补的困难。
有时候，有的软件公司往往为了更快的完成项目，会把软件设计人员和开发人员分成两支不同的组织，一支专门进行软件的设计工作，完成甲项目设计后就快速的投入到乙项目的设计过程中。而研发任务留给研发团队来完成，如果遇到设计上的问题，再由设计团队对软件设计进行调整，由开发团队进行实现上的完善。某种意义上讲，这种模式已经成为软件工业上的主流模式，无数家软件公司正是靠这种方式实现了一个又一个的复杂项目的。
然而，这种模式并非完美无缺，他也造成了一系列问题，尤其是单纯从设计角度来说。例如，由于过份的重视设计，每个开发者只能从某个细节入手进行代码的实现，而可能不知道这个功能在整体项目中的位置，缺乏了对项目的整体思维。例如，由于设计人员本身知识面也好，技能也好，可能导致设计出来的成品根本不符合需求，后期需要花大把的时间进行调整，最终导致设计文档成为没用的负担。
02敏捷开发，解放生产力，从抛弃文档开始
大型软件公司优先意识到这个问题，并对这个模式进行了深入研究，推出了新的理念，极限编程和敏捷开发。在敏捷开发模式中，1，首先要求要抛弃臃肿文档。2，冲刺，以一段时间作为一次冲刺，例如，以两周为一次迭代周期，发一次版本。3，建立里程碑。4，使用看板。5，建立用户故事和统一建模语言来表达一个项目。6，项目组的每一个成员都是团队不可或缺的部分，尽可能的在一个地方办公。7，每天一次例行站立会议。由于敏捷开发极限编程解决了许多现实问题，成为大家广泛使用的行业标准。
互联网公司将敏捷开发用到了极致，然后建立了一套自己的产品发布流程。这个流程有可能是以两周为一次迭代；产品开发周期为五个步骤，需求，原型设计，界面设计，功能开发，测试，发布；使用看板和站立会议，确保任务良好的执行。等等。
对于互联网公司而言，时间就是生命，谁最先开发出优秀的产品，意味着最先抢占先机。从单纯的功能角度来看，互联网公司的产品往往功能点数量并不会很多，因此在短时间内会把每个功能做到极致。一方面，从需求层面来说，要做到满足百分之八十用户的普遍需求，要细化和固化需求，原型设计力求完美，界面设计力求精确到像素点，文案要经得起考验。功能开发层面，选择最成熟的技术方案，做最稳定的功能，确保更高的质量和更稳定的性能。由于前期准备工作充分，在研发阶段的工作量实际上已经越来越少了。于是，开发阶段的冲刺也意味着更侧重于单纯的应用实现，不再需要写方案，画流程，设计数据库，最后才实现功能。
03领域驱动，让程序员心中有码，一剂良方？
从上述过程可以看出来，有的互联网公司实际上已经抛弃了研发设计过程，而更专注于功能实现，开发者的唯一目标就是最快的时间完成任务，不需要太多的想法，不需要过度的设计，纯粹的功能实现而已。问题是，功能设计真的可以丢弃吗？
在互联网公司飞速发展的背后，往往需要更加职能化，专业化的团队，产品开发的背后，实际上是分工明确小团队集体智慧的结晶。但是，由于缺失了研发设计环节，就可能导致研发过程中，功能的开发全凭开发者的个人经验。对于简单的业务，尚且能够掌控，稍微复杂一点的业务就可能需要付出一定的代价才能勉强应付了。由于功能开发取决于个人经验，就可能导致模块的开发，从短期来看满足了眼前的应用指标，但是却为后期的发展留下了弊端。随着原有开发者工作职责的调整，或者离职，将最终导致凭经验开发的功能模块成为无人能维护的神之领域。
在这样的背景下，领域驱动设计成为普遍的选择。实施领域驱动，往往需要由领域专家对系统进行分析，将系统抽象化，然后建立相应的领域模型。实际上领域驱动设计，领域建模同样是非常重要的部分。即团队应使用统一的语言建立软件领域模型，并根据模型来指导开发，其模型应该是能够自我解释，让人通过模型可以理解开发者的意图。通过领域驱动设计，让不同的开发者根据应用场景进行模型设计之后，再按照一致性的规范实现功能，最终可以有效的保证产品研发质量的提升。领域驱动设计的背后，需要开发者不能只专注于眼前功能的实现，而应该能够从全局去了解业务，并充分的将业务吃透，以可传承的知识的形式融入到开发过程中，只有这样才能促进产品更好的开发。然而，领域驱动真的是一剂万能的良方吗？