领域驱动系列四之模型驱动

1、常规以类图作为领域模型开发存在的问题

传统型以技术为驱动的团队,往往喜欢通过类图来展示产品的模型,这样的模型往往存N个对象,这些对象往往存在复杂的关联,产品的创始人,可能能理解整个产品的架构思路,但是如果是新成员,想通过类图去了解该产品,那几乎是不可能的.往往最后还是需要领域专家进行沟通,在结合代码,才能理解这个产品。

而且假设这个类图代表的领域模型是正确的,但是当团队真正的去实现这个模型的时候,发现还是无法将这种错综复杂的模型转换成可存储可转换的事务单元.这里需要解释下,因为前面的文章介绍了,最小化抽象领域的概念,这是领域驱动设计的必然要求,所以当我们结合类图开发是,每次用户的操作,都是以领域对象为单元的.但是因为类图本身的缺陷,所以团队还是无法理解里面错综复杂的关系,特别是操作的领域对象和其它的领域对象有关联时,难度会持续增加.

由于上述的基于类图的领域模型是正确的,因为他是领域专家和开发人员共同讨论的结果,而且最终形成了产品,但是他确不能指导正在进行的开发,而且新员工也无法通过该模型了解清楚整个产品的脉络,所以这样的模型是有问题的.但是他存在的意义会随着时间和人事的变动而逐渐失去他存在的意义.

领域模型种类很多,他们的目的也各有不同,且领域驱动设计要求,模型不仅能够指导前期的分析工作,而且还应该成为设计的基础,我们的代码也必须是结合模型的.

很多设计方法提倡完全脱离于代码的分析模型,而开发人员也喜欢脱离于分析模型的类图模型。领域专家在创建分析模型时可能不会考虑代码层面的可行性,举个例子,之前爆红网络的产品,手机壳变色的事件.哈哈!所以这种分析模型,可能不满足程序设计的需求.而开发人员由于语言鸿沟或者分析模型的理解不彻底,导致编码后核心的领域知识被丢弃的问题,而不得不对模型进行抽象,这个时候问题又产生了,新的模型种将会丢失领域专家嵌入在其中的领域知识.如果这个时候出现了新的领域核心点,但是开发人员觉得这于开发工作不相干而被舍弃,那么这个时候分析模型会被渐渐的弃用,好了,这个时候产生的问题越来越多,最终导致项目失败!

那么我们需要一种方法来解决这个问题,让我们的代码编写能按照领域模型来逐步进行,而且随着代码的编写,模型能健康的生长.

3、领域模型采用的模式和解决方案

如果程序设计核心部分没有和领域模型相对应,那么这个模型没有意义,同时如果模型和设计功能之间过于复杂,在软件设计过程中,无法维护这个关系,那么模型也是存在问题的,需要重新讨论和设计(这个代码重构很想,当一个类很大,或者计算规则很复杂,那么我们就需要对这个类进行重构,保持代码的间接易读).

领域模型采用将分析模型和程序设计结合的方法,来解决这个问题,通过抽象出一个公共的模型同时满足分析模型和程序设计的模型,来达成领域专家和开发人员承认的模型,这样单一的领域模型和可用的.而不是同时存在两个模型,各做各的事情.但是这个过程很艰难,需要长期的头脑风暴,有些甚至不可能.但是必须得这么做.否则随着时间得推移,产品会渐行渐远.

4、面向对象语言得优势(C#)和Model-Driven Design(模型驱动设计)

C#之所以强大,因为他是面向对象并且基于建模范式,我们可以通过他来模拟现实种得场景和对象.像C这种面向过程式得语言,可能表现得比较无力.

5、模型驱动对于用户的重要性

当我们设计系统时,要尽可能让用户得到最多的可配置模型,为什么这么说呢?打个比方,老式的IE浏览器,有一个收藏夹的功能,但是该功能有个缺陷,当用户保存网页时,如果网址种包含非法字符如*/等,那么IE浏览器会悄悄的将这个字符给干掉,但是这样做是非常不好的,这种数据的操作对用户来说时不友好的.应用程序偷偷的修改用户数据，是绝大多用户无法接受的.这个时候如果IE能提供一个可配置的模型,让用户去决定过滤的规则,并适当的提示,并且让用户指定收藏夹的问题等等功能,这些都能通过模型来实现,IE通过该模型来做出正确的反应.这样的模型才是友好的。而不是由IE自行处理,这样用户就变得非常的弱势,那么软件的用户可能随之减少.

6、模型驱动对于开发人员的重要性

如果在项目开发种架构师只负责搭建核心驱动程序的模型,而不参与业务模型的搭建,任由手下的开发随笔的去构建业务模型,那么久而久之,整个产品可能可用,但是随着人事变动,或者业务模块的复杂度增大,那么最后整个领域模型可能也会因此变得不可用.所以这个过程架构师必须配合开发人员共同去构建业务领域模型,这会让开发人员意识到改变业务领域模型,对整个模型是非常重要的,同时开发人员也能从架构师身上学到不少知识.