【领域驱动设计】.NET实践:从需求开始

    在软件系统的整个开发过程中,需求分析是非常重要的一个环节,这一点大家都知道,这句话估计很多人都能脱口而出;然而在实际应用中,却往往容易被人忽视。为什么会出现这种情况呢?我想这也是可以理解的。理论毕竟是理论,与实际应用会有所偏差。比如一些外包项目,由于时间的紧迫,团队必须在较短的时间里做出最快速的反应,如此一来,诸如需求分析、文档管理等过程就会出现混乱,甚至是“避而不谈”,等客户需要相关文档的时候再补。其实这样做也无可厚非,因为实际问题摆在眼前,客户希望在最短的时间内看到结果,至于如何实现,他们并不关心。

 

    然而有的项目,在功能性需求的基础上,客户会对其它的非功能性需求作出要求,例如安全性和高效性,有时候甚至会对项目的实现技术进行干预。比如我有碰到有些客户希望采用.NET来实现整个系统,他们并不会在意,各种软件技术诸如C++和C#的差异有多少,更不会去了解各种技术的优缺点在哪里,当时他们给我的理由是:“现在.NET不是很流行么?就用.NET吧。”。好了,现在让我们从架构设计的角度来看整个系统的设计:我们的客户已经给我们划出了“边界线”:请在.NET的范围内考虑问题!当然你完全可以根据实际情况来决定.NET是否真的合适,如果你发现的确不合适,那么你就应该跟你的客户交涉,提出你的观点,然后双方达成一致。

 

    对于效率要求很高的系统,在系统的其它特性上就会有所保留,比如扩展性。在做设计的时候,你或许会把数据访问机制单独划分到一个层中,通过使用工厂模式或者ORM框架来完成数据库操作,这样做的好处是显而易见的:领域逻辑完全不需要关心对象的持久化细节(怎么保存、保存到哪里等一类技术问题),但它所带来的负面影响就是效率不会很高,起码与ADO.NET的方式相比,效率会有所损耗。因此,此时你不得不在扩展性和高效性上做出抉择,抉择的依据是什么?是客户需求,是系统运行环境的资源分配,是系统在未来一段时间的可变性,同时还有你的设计经验。

 

    回过头来再看功能性需求。其实并非所有的功能性需求都是刚性需求,现在我们把功能性需求简单的分为两种:“刚性需求(Must Have)”和“柔性需求(Nice To Have)”。对于刚性需求,没有办法,你不得不将其实现于你的应用系统中,因为如果不做,那软件系统就不具有解决基本领域问题的能力,也自然无法让客户或者用户接受;而对于柔性需求,我认为,应该在可行、稳定的范围内做选择,这时候也应该跟客户共同商讨。比如,假如客户需求的某个功能并非关键功能,但要实现这个功能却需要投入相当大的人力物力资源,或者在技术上没把握,不能确保它能稳定运行,那么我们可以商讨,要么将这个功能的时间延后(比如放入下个阶段或者下下个阶段再完成),要么直接取消这个功能。

 

    事实上,需求中还有很多隐含的东西,就好比人说话会有隐喻一样。例如做数据传输,那数据的加密、校验也就成了一项不可缺少的功能,本文不深入谈论需求分析,所以在此也就不多说了。由此可见,并非所有需求都能决定软件系统的架构,也不是所有的功能性需求。架构选择是功能性需求与非功能性需求的综合考虑因素。还是引用温昱顾问的那句话:关键需求决定架构。

 

    与现行的软件设计方法一样,领域驱动设计(简称DDD,下同)也应该从需求分析开始。需求分析往往需要客户、领域专家以及软件人员共同参与,领域专家和软件人员共同通过客户了解系统需求,在需求的探讨和分析过程中,两者又与客户进行沟通,尽量在领域模型与软件模型之间做到平衡,而软件人员还要从领域专家那得到相关的领域知识。在实际中,客户和领域专家往往不懂软件,而软件人员又往往不了解领域知识,为了解决这个矛盾,DDD引入了通用语言。所谓通用语言,是建立在领域基础上的一套表达工具,可以是图表,可以是文档,甚至可以是简单的几个文字,关键就是要能够缩小客户、领域专家和软件人员之间的交流沟壑。根据DDD经验,UML不适合用作通用语言,因为它太通用了,不足以表示特定领域。通用语言也不应该是需求分析阶段的专利,只要有交流需要,就可以考虑使用通用语言。

 

    与本节开头所述一样,软件项目完全可以没有需求分析,毕竟很多项目需求实在是简单明了,或者这些项目时间太紧,资源上安排不过来,或者客户图价格便宜,对软件质量要求不高。本节介绍需求分析的目的在于阐明在做软件设计的时候,需要权衡各种因素,再选择合适的架构设计,而这些因素又主要来源于需求。本系列文章介绍DDD在.NET下的实践,但并非是DDD的完全照搬,现实系统中,我们将会遇到很多Anti-DDD的东西。

转载至:http://www.cnblogs.com/daxnet/archive/2009/03/06/1686988.html

此条目发表在C#分类目录。将固定链接加入收藏夹。

发表评论