在大学里的某一天，一个漆黑的夜晚，我来到了一个学校里阴森的图书馆，虽然说不喜欢，但是为了考试不要零蛋，所以拼死也要温书了。来到图书馆的柜台前，遇到了图书管理员。然后我跟管理员说：“我来借书了”，管理员头也不抬的把手一指：“书架在那边，自己去找”。

书架实在是很多，都是分门别类的把书放好在上面的，每个书架上都有标签，标明了这个书架上放的什么类型的书。

于是我一排排的在书架上开始浏览有些啥书

看到一本还不错的书，我就把书取出来，然后看看书的内容

看了看，写的不错，于是拿着这本书去找管理员：“我要借这本啊”。管理员二话没说，拿个本子记下来我借了这本书，然后在书上打个标签

然后我就接到了这本有用地书，然后回去温书考试去了。

以上的内容只是一个简单例子的模拟，而生成的类图也是很粗略的，我们通过对业务行为的分析（经典的借书过程来分析得到上面的图形-为了简单我直接用了VS的类图，其实不是很规范，有很多建模工具可以使用，领域模型的分析没有一定之规所以可能每个人分析出来的模型并不相同，所以如果你觉得有其他的理由，画成了其他的样子，那是完全合理的），回到主题，我们要通过领域模型来驱动我们的设计，但是，我们要弄明白的是什么是领域模型的分析，适合什么地方，什么时候不适合。

领域模型（Domain Model）是一个商业建模范畴的概念，他和软件开发并无一丝一毫的关系，即使一个企业他不开发软件，他也具备他的业务模型，所有的同行业的企业他们的业务模型必定有非常大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，这个东西即“领域模型”。一个掌握了行业领域模型的软件公司，根本不需要再给人家开发项目了，根本不需要靠软件开发养活自己了，你光给这个行业的企业提供业务咨询已经赚得非常丰厚的利润了。

由此我们可知，领域模型的分析并不是我们要做这个软件的时候要做的，而是在这个软件所要实现的业务模式出现的时候就可以开始，所以领域建模比较适合需求比较固定，且业务模式比较成熟的领域。我们首先建立起一个领域模型，然后用最简单直接的类去实现这个模型。这个时候我们不涉及数据库以及持久化等等细节，然后对模型进行精化，利用设计模式将类进行分解，将领域模型的类的职责用多个小类来实现。

比如User类，我们可以用Factory模式加上Facade模式把这个类的职能和持久化行为（数据层的行为）解耦。

其实DDD不一定就是代表着臃肿的实体类，而我们很多时候是在自己设计的时候因为对OO和设计模式的运用不够熟练从而设计出了臃肿的实体类（我自己其实也经常弄出这种类出来-不过通过运用设计模式重构，在大多数情况下是可以改变的）。作为一个合格的程序员，能够快速的完成需求是必要的条件。但是如果只是要求能够做出来实现需求，是不是对自己的要求过低了点，我们不光是需要能跑起来的程序，还需要稳定健壮的程序，更甚的是优美的实现程序，如果仅仅是满足于实现需求，借用星爷的一句话：人没有追求，那和咸鱼有什么分别：）

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号