你的位置:首页 > ASP.net教程

[ASP.net教程]领域驱动设计理论学习笔记之领域模型


      2007年Eric Evans发表《领域驱动设计》至今,领域驱动设计(DDD: Domain-Driven Design)的概念愈来愈被人了解与使用。我已经算是一个后知后觉者,但亡羊补牢,为时未晚。我们对领域这个词非常熟悉,而且经常放在嘴边,但又有多少重视它?开发人员更关注于技术,事实上我也是因为想要研究基于DDD的ASP.NET开发框架ABP(ASP.NET Boilerplate)。ABP是个开源框架,其分层框架,其代码逻辑有许多值得学习的地方,但如果要真正掌握它,我认为还是先从理论上理解,从思想上做些改变,所谓磨刀不误砍柴工就是这个道理。
      领域驱动设计(DDD: Domain-Driven Design)的核心在于领域模型,首先是要通过足够的沟通交流建立起一个领域模型,然后由领域模型驱动软件设计,用代码讲这些概念设计成一个领域模型。如何沟通交流?需要一种领域专家、软件设计人员、开发人员都能够理解的通用语言,曾经UML似乎就是希望作为一种建模语言,达成从分析到设计到编码的平滑过渡,但实际上UML在分析与设计上依然存在鸿沟,而且有很强的专业性。
      领域模型很重要和必要,那么领域模型有什么特点?
      领域模型是对某个领域的抽象,这个领域模型是有边界的,模型反应领域内我们关注的部分。这很好理解,任何一个系统的需求都有其边界,项目管理的范围管理也是在管理一个项目的边界,这会使得工作变得可控。
      领域模型并不是要尽可能符合“现实”的模型。即使对真实世界如何的建模,那也是一种模拟。建立领域模型是出于某种目的而概括的反应现实,类似于电影,用一种特殊的方法展现给观众,讲一个故事,阐述一个观点。
      领域模型只反映业务,与技术实现无关。比如人力资源领域、供应链领域与开发技术实现无关,但也有开发技术密切相关的领域,比如源代码管控系统,软件集成开发环境等。关于需求与设计的区别,一直有两种说法,直白的一种说法是:需求是关于要做什么,设计是关于要怎么做;另一种说法是:需求是关注业务领域,设计是关注技术实现。从这个角度看,领域模型是用于需求分析,或者确切的说是需求分析的工作产品。
领域模型是浓缩的知识,确保软件的业务逻辑在一个模型中,方便业务的理解。领域模型能够帮助开发人员平滑的将领域知识在转化为软件实现。事实上,开发人员绝大多数时候对业务领域并不熟悉,甚至可能完全不懂,这需要在开发前对开发人员做必要的业务培训。领域模型经过了提炼,可以更有效率的做到沟通。关键还在于围绕着领域模型,我们可以实现组件化,提高复用,也促使软件有更好的维护性。
      领域模型贯穿软件需求分析、设计、开发的整个过程,成为一个团队所有成员交流沟通的核心纽带,大家面对的是同一个模型。旧的观念认为需求人员开发需求规格,设计人员研究需求规格编写设计书,开发人员依据设计书编写代码。领域驱动设计显然不认可这种做法,开发人员不仅要能理解领域模型,还需要为领域模型的细化和完善做出贡献。这也意味着领域模型贯穿软件开发的整个生命周期,不断的更新。
      领域模型作为沟通的工具是可见的,需要表达出来。这种表达最常用的是图,也可是代码或文字描述。对这一点我是很好奇的,图很容易理解,比如用例图、流程图,代码怎么表达模型而让领域专家能够看懂?DDD建立一种名叫UBIQUITOUS LANGUAGE的领域通用语言或者说是模式。