某智能制造公司计划开发一个内部的需求管理系统，用于内部收集需求并改进软硬件产品。 硬件产品需求由硬件部门负责承接，为完成硬件产品需求，涉及联系供应商采购零部件，采购合同等。硬件产品需求从提出到实现，需要经由提交、审批、采购等流程，其中审批环节需由部长审批。 而软件产品均为自研，软件产品需求由软件部门的某个Scrum敏捷团队以「用户故事」承接并开发，无需外部采购。软件产品需求从提出到实现，需要经由提交、审批、设计、开发、测试和发布等流程。审批环节由软件部门技术总监审批即可。

要实现这个需求管理系统，开发团队和领域专家共同讨论并设计出了以下模型：

硬件产品需求生命周期：

软件产品需求生命周期：

完成这个初稿设计后，领域专家Mike离开会议室去接了一杯水。 开发团队的资深开发工程师Jack提出：“虽然硬件产品需求和软件产品需求的流程有所不同，但它们都是产品需求，我们可以整合为一个模型，不需要区分软硬件”，说完后，他就在白板上画出了以下模型：

“这个模型没有「零部件采购单」，只有「采购单」，也没有「硬件产品需求」和「软件产品需求」” – Jack说道。 “你们用过Jira吗？它看起来很酷，用看板可视化所有需求，所有用户可以在看板上协作。Jira把看板上的卡片称为Issue，Issue可以是需求，也可以是缺陷。如果我们也这么设计，系统未来还可以承接修复缺陷。 采购单可以参考Jira Workflow工作流来设计，这样我们可以通过配置工作流来支持所有的业务流程了，包括采购流程。” – 初级工程师Mike改进了白板上的模型：

开发团队成员纷纷表示赞同。 此时，领域专家Mike回到了会议室，开发团队向领域专家说：”Mike，我们有一个更好的设计！“。 Mike看到了白板上的模型，一脸疑惑。他不理解Issue以及工作流到底是什么，Jack解释说： ”Issue可以通过类型来区分，当类型是软件产品时，它就会关联上一个「用户故事」，当类型是硬件产品时，它就关联上一个「工作流」去走采购流程，这种抽象设计，让系统的扩展性更好，以后可以扩展支持更多的Issue类型和流程！我们参考了Jira看板产品设计“。 Mike：“那为什么我不直接去买一个Jira产品呢？“

以上场景改编自笔者的真实经历。 开发团队改进后的模型可以解决问题吗？当然可以！两种模型都可以有效地解决问题，两者本质区别在不同的抽象层级上，前者的概念模型更契合当下要解决的问题领域，非常容易理解，而后者会更抽象一些，不那么容易理解，扩展性会更好，但容易过度设计，为不存在的需求投入过多成本。

DDD领域驱动设计建议开发团队邀请领域专家共同探讨，建立通用语言。如果领域专家和开发团队一直在使用不同的语言进行沟通，在后期将导致沟通困难、软件难以理解、维护困难。虽然高度抽象的模型看起来非常诱人，但通过对当下的业务需求进行建模，你将节省大量的时间、预算和代码，因为不再需要去解决一些目前不存在的需求。

如果你的组织可以确定当下开发的软件需要支持各种不同业务，在综合评估开发成本过后，可以考虑选择更高层级的抽象模型，或者直接选择去购买一个外部产品。