文章目录一、需求人员如何利用领域模型1、解决用户参与不够的问题2、解决分析瘫痪的问题二、开发人员如何利用领域模型1、从词汇表到领域模型从点到面的跨越2、领域模型如何帮助理解复杂业务表达出关系画出领域模型与状态图从业务的点、线、面来把握业务的整体认知3、领域建模是一个渐进的过程三、总结领域模型是团队的沟通工具和思维工具核心观点领域模型就是需求人员和业务人员沟通的 “大白话词典”也是帮大家跳出 “越聊越乱” 的实用工具。它能让业务人员全程参与需求讨论不用靠需求人员瞎猜还能把复杂问题拆成一个个好处理的小部分避免聊来聊去没结果。一、需求人员如何利用领域模型领域模型就是需求人员和业务人员沟通的 “大白话词典”也是帮大家跳出 “越聊越乱” 的实用工具。它能让业务人员全程参与需求讨论不用靠需求人员瞎猜还能把复杂问题拆成一个个好处理的小部分避免聊来聊去没结果。1、解决用户参与不够的问题传统的需求分析方式往往是需求人员听用户说然后整理成文档。这种方式的问题在于用户说的和需求人员理解的可能不一样。就像两个人看同一张地图一个人说往东走另一个人理解的东可能不是真正的东。领域建模提供了一个解决方案让用户代表或领域专家深度参与领域建模活动。在画领域模型的过程中需求人员和业务人员会不断讨论、澄清、确认。这个过程本身就是深度沟通可以让需求人员的理解从假设变成共识。例如在讨论银行账户的挂失功能时如果只是听用户说挂失就是账户不能用了需求人员可能会假设挂失就是删除账户或挂失就是冻结账户。但通过画状态图需求人员和业务人员会一起讨论挂失是什么状态是账户的一种状态不是删除账户从什么状态可以变成挂失从正常状态可以变成挂失状态挂失需要什么条件需要身份证验证挂失后可以做什么不能进行存款、取款等交易挂失后怎么恢复通过身份证解挂可以回到正常状态挂失和冻结有什么区别挂失是用户主动申请的冻结是银行根据授权如司法授权操作的这样需求人员的理解就从假设变成了共识。更重要的是通过画状态图还发现了业务规则开户时开户金额必须≥10元人民币这个规则如果不通过建模讨论可能被忽略。更重要的是领域模型关注的是问题域本身而不仅仅是想要的功能。就像盖房子不仅要讨论要几个房间更要讨论房间之间的关系、“房间的用途”、“房间的约束”。这种讨论让需求人员和业务人员对业务的理解更加深入和稳定。再看一个例子在讨论项目管理系统的任务分配功能时如果只是问任务怎么分配用户可能说分配给项目成员。但通过领域建模会发现很多细节一个任务只能分配给一个人还是可以分配给多个人通过建模发现一个任务只能分配给一个人但一个人可以负责多个任务一对多关系任务分配后可以修改吗可以但需要记录分配历史任务分配和资源分配是什么关系资源被项目占用但具体使用是分配给任务的任务分配资源时需要记录使用期限任务可以分配给团队吗最初可能只考虑分配给个人但通过建模讨论发现未来可能需要支持分配给团队或部门这些细节如果不通过领域建模深入讨论可能要到编码时才发现问题。比如如果数据库设计时只考虑了分配给个人后来要支持分配给团队就需要修改数据库结构成本很高。更重要的是领域模型定义的领域词汇应该成为团队所有活动的沟通基础。当开发者问用户详细的需求问题时当系统分析师争论需求文档时当测试人员争论bug时都应该使用领域模型定义的词汇。这样沟通才能准确、有效。2、解决分析瘫痪的问题有些项目一分析需求就停不下来讨论来讨论去就是定不下来。比如银行系统中客户、账户、凭证之间的关系到底怎么理解“一卡通”、一折通这些概念反复讨论就是理不清楚。这种分析瘫痪的根本原因往往是对关键领域问题的理解不够深入。就像两个人讨论怎么去北京如果连现在在哪里都没搞清楚讨论再多路线也没用。领域建模提供了一个渐进式的方法理解一点画一点公开讨论再理解一点再画一点。就像盖房子不是一次性把所有图纸都画完而是先画地基再画框架再画细节。每画一层团队的理解就深入一层讨论就聚焦一层。例如在软件配置管理系统的开发中最初的理解可能是零散的有角色、“工件”、“变更”、基线这些概念但关系不清楚。通过不断建模逐渐发现角色执行活动活动可以生产、使用、修改工件工件产生变更但不是所有变更都需要管理只有受控的变更才能纳入基线配置项是工件的子类只有通过评审的工件才能成为配置项基线由多个配置项组成是配置项在某个时间点的快照这样的关系链最终形成一个完整的领域模型。这个过程就像拼图一块一块地拼最终拼出完整的画面。更重要的是这个过程是公开的、迭代的。每画一层模型就公开给整个项目团队讨论。这样不仅需求人员的理解在深入整个团队的理解也在深入。就像层层夯实理解一层建模一层讨论一层再理解一层再建模一层。在敏捷社区有一个著名的案例新加坡贷款项目。这是一个巨大的失败一家大型系统集成公司花了两年时间最终放弃。这个项目涉及广泛的贷款系统整合了各种贷款凭证和贷款功能。但同样的问题一个叫Jeff的人却成功了。他的成功秘诀之一就是领域建模。在开始新项目后的两个月内Jeff的团队就开始向客户提供可演示的功能而他们花了大约一个月的时间进行整体对象建模。这个案例说明领域建模不是浪费时间而是节省时间。花时间把领域模型搞清楚可以让后续的开发更顺利避免返工。二、开发人员如何利用领域模型领域模型就像拼图游戏把零散的业务词汇拼成完整的业务图景。它不仅能帮你理解单个概念更重要的是帮你理解概念之间的关系从而形成对业务的整体认知破解领域知识不足的死结。很多开发人员都有这样的经历拿到一个需求文档里面有很多业务术语每个术语的定义都看懂了但就是不知道它们之间有什么关系也不知道业务到底是怎么运作的。就像看一本字典每个字都认识但连成句子就不知道什么意思了。这就是领域知识不足的典型表现。1、从词汇表到领域模型从点到面的跨越对于开发人员来说收集业务词汇是理解领域的第一步。可以从用户手册、业务文档中收集特别是从类似项目的领域词汇列表中收集。这些文本描述可以作为领域建模的输入。例如在在线拍卖系统中词汇表可能会这样定义拍卖一种销售方式将物品卖给出价最高者拍卖信息拍卖活动的信息包括开始时间、持续时间、拍卖项列表等拍卖项被拍卖物品的统称拍卖项信息拍卖项的信息包括商品信息名称、描述、图片、分类、起拍价、最低加价幅度等起拍价初始最低出价成交价拍卖结束时的最高出价买家参与竞价的参与者卖家提供商品并通过拍卖销售的人成交拍卖物品的所有权从卖家转移到最高出价者买家支付成交价这些定义都很清楚但看完之后开发人员可能还是不知道一个拍卖可以有几个买家一个买家可以参与几个拍卖成交是怎么发生的成交记录了哪些信息这些关系词汇表说不清楚但领域模型可以画清楚。在领域模型中开发人员会看到类图部分商品是父类拍卖商品继承商品有起拍价和加价幅度属性买家和卖家通过成交这个关联类连接成交记录了拍卖商品、买家、卖家、成交价、成交时间。这样开发人员就知道需要定义Product类、AuctionItem类继承Product、Buyer类、Seller类、Transaction类关联类Transaction类包含AuctionItem、Buyer、Seller的引用以及transactionPrice和transactionTime属性。状态图部分在线交易的交付过程从已订购状态开始买家预付后变成已预付状态卖家发货后变成已发货状态买家确认支付后变成成功状态。但如果买家申请退款从已发货状态可以转到申请退款状态卖家同意退款后变成失败状态。这些状态之间的转换用状态图画出来开发人员就知道需要定义OrderState枚举需要实现状态转换的方法需要检查状态转换的条件。这样整个业务流程就清晰了卖家发布拍卖项买家出价最终最高出价者与卖家形成成交关系然后进入交付流程。对于开发人员来说这种可视化的表达方式让抽象的业务规则变成可以讨论、可以验证的图形。就像看地图比听人指路要清楚一样看领域模型比听业务人员描述要准确。2、领域模型如何帮助理解复杂业务表达出关系画出领域模型与状态图在软件配置管理系统的开发中最初的领域模型可能很简单有角色、“活动”、工件这些概念。但随着建模的深入会发现很多隐藏的规则角色通过执行活动来体现职责活动可以生产、使用、修改工件不是所有工件都需要管理只有通过评审的工件才能成为配置项基线是多个配置项的快照只有受控的变更才能纳入基线这些规则如果只用文字描述开发人员很容易遗漏或理解偏差。但用领域模型画出来关系就清楚了工件和配置项是继承关系配置项和基线是组合关系变更和受控变更是继承关系。这样业务规则就变成了可以验证的模型结构。很多业务概念不是静态的而是有生命周期的。比如银行账户从开户到销户中间可能经历挂失、解挂、冻结、解冻等状态变化。这些变化用状态图画出来比用文字描述要清晰得多。更重要的是状态图还能展示状态转换的条件。比如在银行账户的状态图中从初始状态到正常状态需要开户[开户额≥10]这个事件这意味着开户时不仅要触发开户事件还要检查开户金额是否≥10元从正常状态到挂失状态需要挂失[身份证]这个事件这意味着挂失时需要验证身份证从挂失状态回到正常状态需要解挂[身份证]这个事件这意味着解挂时也需要验证身份证从正常状态到冻结状态需要冻结[授权]这个事件这意味着冻结需要授权如司法授权从冻结状态回到正常状态需要解冻[授权]这个事件在正常状态下可以进行存款和取款交易自转换这些条件如果只写在需求文档里开发人员可能忽略但画在状态图里就一目了然。对于开发人员来说状态图直接对应到代码实现。比如看到状态图就知道要定义一个AccountState枚举NORMAL, LOST, FROZEN, CLOSED要定义状态转换的方法reportLost(idCard), unreportLost(idCard), freeze(authorization), unfreeze(authorization)要定义状态转换的条件检查开户金额≥10身份证验证授权验证。这样业务规则就变成了可以实现的代码逻辑。从业务的点、线、面来把握业务的整体认知单个概念的理解是点概念之间关系的理解是线业务流程的理解是面。领域模型帮助开发人员把点连成线把线连成面最终形成对业务的整体认知。例如在项目管理系统中开发人员最初可能只知道有项目、“任务”、资源这些概念。但通过领域建模会发现项目分解成任务任务分配给项目成员资源被项目占用但具体使用是分配给任务的任务之间有前后关系影响项目进度项目有状态变化从未启动到进行中到已完成或已取消这样整个项目管理的业务逻辑就清晰了项目是容器任务是工作单元资源是支撑状态是监控。这种整体认知是单个概念的理解无法提供的。对于开发人员来说这种整体认知直接指导代码的组织方式。比如看到项目是容器就知道Project类应该包含Task的集合看到任务分配给项目成员就知道Task类应该有一个assignedTo属性看到任务之间有前后关系就知道要定义一个TaskDependency类。3、领域建模是一个渐进的过程领域建模最初的理解可能是零散的、不完整的但随着讨论的深入模型会越来越清晰越来越系统。在软件配置管理系统的案例中最初的领域模型只有四个概念角色、工件、变更、基线关系也不清楚。但随着讨论逐渐发现角色和活动的关系角色执行活动活动和工件的关系活动生产、使用、修改工件工件和变更的关系工件产生变更配置项和基线的关系基线由多个配置项组成最终形成了一个完整的领域模型不仅包含了核心概念还包含了它们之间的关系甚至包含了业务规则比如只有受控的变更才能纳入基线。对于开发人员来说这个过程就像代码重构理解代码一样。最初可能只知道有几个类但不知道它们之间的关系。通过不断抽象和整理逐渐发现类之间的关系最终形成清晰的代码结构。领域建模也是一样通过不断抽象和整理业务概念逐渐形成清晰的领域模型。三、总结领域模型是团队的沟通工具和思维工具领域模型对需求人员的价值主要体现在两个方面一是作为沟通工具让业务人员深度参与需求分析避免假设过多二是作为分析工具让复杂问题分解成可管理的小块避免分析瘫痪。领域模型对开发人员的价值主要体现在三个方面一是帮助理解概念之间的关系而不仅仅是单个概念二是帮助发现隐藏的业务规则而不仅仅是表面的功能三是帮助形成对业务的整体认知而不仅仅是零散的知识点。因此需求人员和开发人员都应该主动使用领域建模。需求人员应该在发现用户参与不够时邀请用户一起画领域模型在发现需求分析陷入僵局时用领域建模渐进式地推进理解。开发人员应该在面对陌生的业务领域时不要急于写代码先花时间做领域建模从收集业务词汇开始到画出初步的领域模型再到不断迭代完善。更重要的是领域建模不是一个人的工作而是团队的工作。需求人员、开发人员、业务人员、架构师、测试人员都应该参与进来。在这个过程中不仅领域模型会越来越清晰团队对业务的理解也会越来越一致。这种一致性是项目成功的基础。最终对业务的理解越深入需求分析的质量就越高代码的质量就越高系统的扩展性就越好。领域建模就是帮助团队达成这种深入理解的关键工具。