`
fangang
  • 浏览: 876507 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
311c4c32-b171-3767-b974-d26acf661fb2
谈谈用例模型的那些事儿
浏览量:38625
767c50c5-189c-3525-a93f-5884d146ee78
一次迭代式开发的研究
浏览量:68798
03a3e133-6080-3bc8-a960-9d915ed9eabc
我们应当怎样做需求分析
浏览量:409841
753f3c56-c831-3add-ba41-b3b70d6d913f
重构,是这样干的
浏览量:91341
社区版块
存档分类
最新评论

我们应当怎样做需求分析:领域驱动设计

阅读更多
2007年,世界级的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》,进而形成了一套独特的软件分析与设计方法,简称为DDD(Domain-Driven Design)。在领域驱动设计思想中,有许多是涉及到需求分析领域的先进方法,我把它归纳为有效建模、统一语言和持续学习。

有人说:大师所站的高度实在太高了,是生活在太空里的,所以我们要追随大师就只有因为缺氧而死掉。我认为这句话说得非常生动,学习大师真的不是一件容易的事,把大师的思想落实到我们的工作中更难,常常还伴随着一些不小的风险,学习伊大师也是一样的。

伊大师一上来就提出了要有效建模的思想,我当时立马就晕菜了。按照这个思想,我们应当在业务研讨会上,与客户讨论业务需求的时候就开始现场建模了。这!怎么可能呢?客户看得懂那些专业的、抽象的模型吗?我们能拿着模型与客户交流吗?这是不是在浪费时间?

的确,伊大师提出了有效建模思想,与其它很多诸如在会后分析整理时进行的原文分析方法大相径庭。同时,这个思想认为,我们应当与客户代表形成一种统一的语言,一种混合语言。这种语言,既有软件技术中的元素,又有业务领域中的术语,同时,它又是技术人员与业务人员都能理解的语言。使用这个语言,技术人员与业务人员就是在用同一语言在沟通与讨论问题,这种沟通的障碍就得以消除。

道理简单实践难,什么是有效的建模,什么是统一的语言呢?经过无数的实践与尝试,我逐渐开始明白了。首先,什么是有效的建模呢?当我们作为非专业人员去看一个建筑设计师绘制的图纸时,我们一看就明白这是一栋楼房,那是一座桥梁,为什么?因为图纸形象生动,没有那么多专业术语,我们一看就明白了。软件中的设计图也是一样的道理。

当我们站在技术人员的视角去绘制设计图时,客户必然看不懂,因为图中使用的都是专业的术语、专业的符号,表达的都是专业的设计思想。反过来,如果我们站在业务人员的视角去绘制设计图时,情况就不一样了。如果一个用例图,图中的功能都是客户日常经常做的业务操作,并且命名都是业务人员能够理解的业务术语,试问客户会不理解吗?同样,在领域模型中,我们按照客户的思路,运用客户的术语,去绘制一个一个的对象,按照他们的思路去描绘对象间的关系,描绘对象间的操作,他们真的就会看不明白吗?这说得似乎有一些抽象,我们举一个实际的例子吧。

有一次,我与客户在讨论一个考核系统,首先客户描述着他们的需求:
客户:我们这个考核系统是由许多个考核指标组成的,每个考核指标就标志着我们的某项工作的完成情况。每个考核指标中有一个分母数,标志某段时间所有应当完成的工作数量,有一个分子数,标志这段时间正确完成的工作数量,最后还有一个过错数,标志那些错误的,或者没有按时完成的工作数量。
需求人员:为什么是分子分母?
客户:因为最后要计算正确率,用正确率来考核一个单位完成工作的情况。
这样,我们在纸上绘制出一个考核指标,在属性中写下分母数、分子数、过错数、正确率。

需求人员:那么每个考核指标都有一个过错判断标准了?
客户:当然啦,每个考核指标都有它的过错判断标准。一个考核指标可能会有多个过错行为,每一个过错行为都有各自的过错判断标准,任何一个过错了,这个执法行为就算过错啦。
需求人员:先等等,你刚才提到执法行为了。执法行为和考核指标是什么关系?
客户:哦,执法行为嘛,就是执法人员对某个用户执行的一次业务操作。考核指标中的分母数就是所有执法行为的个数;分子数就是正确的执法个数;过错数就是错误的执法个数。
这样,我们就绘制出这样一个草图:



客户看了这个草图有些不同明白:过错类型是什么东西?
需求人员:过错类型就是某种类型的过错行为呀,它定义了某种过错行为,有它的过错判断标准。下面这个过错行为就是那些具体的过错,比如张三今天犯了什么错,李四明天犯了什么错。
客户:哦,明白。这两个箭头怎么跟其它箭头不一样,后面还跟了个菱形框?
需求人员:哦,这代表的是包含关系,表示一个考核指标包含了多个类型的过错行为呀。

经过一番交流,我们已经明白客户的意思了,客户也明白我们画的图了。大家对彼此的交流都比较满意。

所有的爱情都是以浪漫开始的,需求分析也不如此。随着需求分析的不断深入,我们发现问题了。在这张图中,我们把执法行为与过错行为仅仅描述为一对多的包含关系,似乎没有什么特别的。但对大量考核指标具体需求的分析,我们才发现其实不是这样简单。当考核指标只有一种过错行为的时候,那非常简单,这个过错行为对就是对,错就是错。但当考核指标存在多种过错行为的时候,情况就复杂了,必须分成三种情况:

1. 一个执法行为同时包含多种过错行为,每个过错行为就是一个考核点,任意一个考核点错了整个就判错,只有所有考核点都正确才判正确。这种情况就像填一个表单,所有数据项都填对了才算对,任意一个错了就算错,然后画出这样一个对象图:



2. 虽然一个考核指标定义了多个过错行为,但它把所有执法行为分为多个类型,每个类型的执法行为只对应一个过错行为,这个过错行为对就是对,错就是错:



3. 最后一种就是那些限期完成的考核指标,正确的行为只有一个:按时完成的行为,过错行为却有两个:逾期完成与逾期未完成。



虽然图形有些复杂,但这正是代表了现实世界业务的复杂性。我们拿着这些图与客户进行了简单的描述,由于图中的所有元素都是用客户熟悉的术语描述的,因此他们很快就能够理解。同时,开发人员拿到这样一个图,很快就制订了四套不同的方案,来分别解决四种不同的情况。

随后,在对这四种情况更加深入的分析时,我们发现第一种情况在计算过错数时似乎有一些问题。在第一种情况中,一个执法行为包含了多个过错行为,如果出现了过错,过错数算几?假如一个执法行为包含三个过错行为,如果都做对了,分子数算1;但假如有2个过错行为错了,过错数算2?还有那一个正确的行为呢?这似乎有些矛盾!当我们向业务人员提出这个问题时,他也有些懵了,这样的结果似乎是我们双方都没有预料到的。经过反复的思考与讨论,最后我们做出这样的决定:将原有的过错数拆分成过错户与过错数。在以上情况中,如果一个执法行为有2个过错行为错了,过错户为1,过错数为2。试想,如果不对需求进行如此深入分析与理解,能发现这样的问题吗?如果不及早发现这样的问题,是否会给项目后期带来巨大的风险?

应该说,从最初的粗浅认识,深入到后来对四种情况的认识,正是体现了DDD的另一个思想:持续学习。需求人员在开始一个新的管理系统的分析工作时,都有可能面临着一个全新的业务领域。在这个领域中,他们不可能一夜成为专家,也不必要成为专家。他们需要时间去学习领域知识,但这并不意味着学习所有的领域知识,而是与软件相关的领域知识。做财务软件,你不必考财务师,但你必须要学会与财务软件相关的财务知识。你对领域模型的认识被延伸到了整个软件生命周期中,包括之后一次一次的升级完善。你每认识深入一点儿,就可能会体现到你的分析设计中,并最终体现在开发的软件中。你对领域知识认识再深入一点儿,软件就再完善一分。

我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会

(续)
  • 大小: 48.1 KB
  • 大小: 82.9 KB
  • 大小: 68.3 KB
  • 大小: 62.8 KB
分享到:
评论
3 楼 fangang 2012-04-25  
当然这不是领域驱动设计的全部,只是在需求分析这个阶段的部分,因为这里的主题是需求分析。关于设计开发的部分我今后在其它文章里讨论吧
2 楼 sunway00 2012-04-25  
关于领域驱动方面,楼主写的不够详细哦,期待后面更详细的方面,比如在需求与设计的对接、需求变动的管理等
1 楼 sunway00 2012-04-25  
一口气从第一篇看到这里。楼主的文章写道我心坎里去了,我也做了差不多快2年的需求了,很多经验、教训都在楼主的文章中清楚的体现出来,看到时候有恍然间时光倒流回到自己原来调研、分析的时候。感谢楼主的分享。

相关推荐

    我们应当怎样做需求分析

    我们应当怎样做需求分析:领域驱动设计 39 我们应当怎样做需求分析:非功能需求 44 我们应当怎样做需求确认:需求列表 46 我们应当怎样做需求确认:一个需求列表的实例 48 我们应当怎样做需求确认:快速原型法 49 ...

    领域驱动设计和开发实战.pdf

    ### 领域驱动设计与开发实战:关键知识点解析 #### 一、领域驱动设计(DDD)概述 **领域驱动设计(Domain-...通过上述关键知识点的介绍,我们可以更好地理解领域驱动设计的核心理念及其在软件开发中的应用价值。

    产品思想——领域驱动设计

    在软件开发领域中,"领域驱动设计"(Domain-Driven Design,简称DDD)是一种特别强调软件中领域模型重要性的方法论。它由Eric Evans在其2003年发表的同名著作中提出,并且随着实践发展不断演进。DDD不仅仅是关于软件...

    领域驱动设计在重构业务系统中的实践.docx

    ### 领域驱动设计在重构业务系统中的实践 #### 一、背景介绍与问题提出 随着业务的不断发展和技术的进步,传统的系统架构逐渐暴露出一些不足之处,尤其是在处理复杂业务逻辑方面。在这种背景下,领域驱动设计...

    Domain+Driven+Design 领域驱动设计

    为了应对领域驱动设计的复杂性,书中也提供了相关的分析模式,帮助开发者将设计模式与领域模型关联起来。例如,策略模式(Strategy)用于表示在不同情况下,业务规则或算法的变化,而组合模式(Composite)则用于...

    用户力:需求驱动的产品、运营和商业模式-郝志中 -

    《用户力:需求驱动的产品、运营和商业模式》是郝志中所著的一本书,它深入探讨了在现代商业环境中,如何以用户需求为核心,构建成功的产品、运营策略以及商业模式。这本书的知识点涵盖了多个方面,包括产品设计、...

    软件需求电子书

    《软件需求电子书》是一本深入探讨软件需求分析与管理的专业读物,旨在帮助读者更好地理解和执行需求工程的各个环节。这本书以PDF格式呈现,带有清晰的目录结构,使得读者能够快速定位到感兴趣的主题,提高学习和...

    天工大义系列之一:线性驱动专题研究,线性驱动赛道在拓宽,国产品牌追赶中替代.rar

    近年来,随着科技进步和市场需求的增长,线性驱动赛道逐渐拓宽,国产线性驱动品牌也在积极追赶,试图在国际竞争中占据一席之地。这篇《天工大义系列之一:线性驱动专题研究》将深入探讨这一领域的现状、发展趋势以及...

    架构设计中领域模型设计思路

    在领域驱动设计(DDD)中,这类组件通常被设计为领域服务,协调领域实体之间的交互。 5. `InMoney` 和 `InMoneyBP1310`:这两个类可能与资金流入(收入)相关,可能是领域模型中的两种不同类型的收入事件或者状态。...

    全球AI推理服务器市场洞察:技术驱动下的市场繁荣与未来展望.pdf

    ### 全球AI推理服务器市场洞察:技术驱动下的市场繁荣与未来展望 #### 一、引言 在当今人工智能(AI)技术飞速发展的背景下,AI推理服务器作为支撑AI应用落地的重要基础设施,扮演着越来越重要的角色。随着数据量...

    计算机软件设计方法的探讨借鉴.pdf

    1. 需求分析:在软件设计的最初阶段,需求分析是一项必不可少的工作。它要求与客户或用户进行沟通,明确系统需求,包括功能性和非功能性需求。需求分析的结果通常是需求规格说明书,这将指导后续的设计工作。 2. ...

    软件需求设计UML全程实作--愿景UMLChina

    总之,文档中呈现的是一种以UML为工具,由愿景驱动,贯穿业务建模、需求分析、分析设计,直到软件设计的完整软件开发流程。这有助于项目团队更好地理解业务需求,高效地沟通,并确保最终软件产品能够有效地解决实际...

    领域建模PPT(bang网站上的)

    领域驱动设计(DDD)是一种软件开发方法,旨在通过构建领域模型来应对复杂系统的挑战。该方法由Eric Evans在2004年的著作《领域驱动设计:应对软件核心复杂性》中提出。领域模型是一种用于理解和表达业务领域的抽象...

    LED灯具最佳驱动方式分析

    总结起来,LED灯具最佳驱动方式分析告诉我们,恒流驱动不仅能够保证LED灯具的性能,确保安全性,还可以延长灯具的使用寿命,从而达到一举三得的效果。在设计和应用LED灯具时,应当优先考虑采用恒流驱动方案,避免...

    基于DDD和微服务中台架构与实现

    【基于DDD和微服务的中台架构与实现】是一本深度探讨现代企业IT架构的书籍,作者欧创新和邓頔结合实践经验,阐述了如何利用领域驱动设计(DDD)和微服务架构构建灵活且高效的中台系统。以下是该书涉及的主要知识点:...

    IT通讯电子器件行业阻流圈领域分析报告(研究报告).pdf

    5. 需求分析与预测:报告可能依据当前市场的需求变化,预测了未来几年内阻流圈的需求趋势,包括主要驱动因素、影响因素和市场潜在的增长点。 6. 关键成功因素和风险分析:在这样的报告中,通常会分析影响阻流圈市场...

Global site tag (gtag.js) - Google Analytics