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

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

阅读更多
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

    大三下复杂软件的设计之道:领域驱动设计.pdf

    领域驱动设计:软件核心复杂性应对之道.pdf

    领域驱动设计:软件核心复杂性应对之道

    领域驱动设计:软件核心复杂性应对之道

    领域驱动设计:软件核心复杂性应对之道领域驱动设计:软件核心复杂性应对之道领域驱动设计:软件核心复杂性应对之道领域驱动设计:软件核心复杂性应对之道领域驱动设计:软件核心复杂性应对之道领域驱动设计:软件...

    实现领域驱动设计(pdf)

    领域驱动设计(DDD)是教我们如何做好软件的,同时也是教我们如何更好地使用面向对象技术的。它为我们提供了设计软件的全新视角,同时也给开发者留下了一大难题:如何将领域驱动设计付诸实践?Vaughn Vernon 的这本...

    领域驱动设计:软件核心复杂性应对之道

    《领域驱动设计:软件核心复杂性应对之道》是领域驱动设计方面的经典之作。全书围绕着设计和开发实践,结合若干真实的...《领域驱动设计:软件核心复杂性应对之道》适合各层次的面向对象软件开发人员、系统分析员阅读。

    实现领域驱动设计

    领域驱动设计(DDD)是教我们如何做好软件的,同时也是教我们如何更好地使用面向对象技术的。它为我们提供了设计软件的全新视角,同时也给开发者留下了一大难题:如何将领域驱动设计付诸实践?Vaughn Vernon 的这本...

    领域驱动设计.epub_ddd_

    领域驱动设计:学习DDD领域驱动设计实践,更好的设计自己的程序

    领域驱动设计.rar

    三本领域驱动设计的书籍整合: 领域驱动设计与模式实战.pdf 领域驱动设计.pdf Domain_Driven_Design_GAP平台领域驱动设计.pdf

    领域驱动设计.epub

    领域驱动设计 软件核心复杂性应对之道 修订版 epub电子书

    领域驱动设计(简版和完整版)

    领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域驱动设计(简版和完整版)领域...

    DDD领域驱动设计-精简版.pdf

    DDD领域驱动设计

    领域驱动设计.mobi

    领域驱动设计.mobi,英文原文,适用于在kindle上阅读。

    领域驱动设计与模式实践.pdf

    领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中。大部分关于此主题的著作和文章都以Eric Evans的书《领域驱动设计》为基础,主要从概念和设计的角度探讨领域建模和设计情况。这些著作讨论实体...

    领域驱动设计C#2008实现 - 问题.设计.解决方案,完整扫描版

    《领域驱动设计C# 2008实现:问题·设计·解决方案》是第一本也是唯一一本关于使用C#实现领域驱动设计的技术书籍,《领域驱动设计C# 2008实现:问题·设计·解决方案》介绍了构建实际应用系统的全过程。《领域驱动设计...

    领域驱动设计C# 2008实现问题.设计.解决方案

    3.2.1 设计领域模型 3.2.2 定义项目聚合 3.2.3 定义聚合边界 3.2.4 设计仓储 3.2.5 编写单元测试 3.3 解决方案 3.3.1 project类 3.3.2 实现仓储 3.3.3 实现服务类 3.3.4 实现项目信息视图模型 3.3.5 实现...

    领域驱动设计案例-盒马实践

    很好的文档介绍盒马的领域驱动设计实践案例

Global site tag (gtag.js) - Google Analytics