许多人或许会对我的这种做法提出质疑，不错，很多的流行书籍都告诉我们，在整理完需求以后，可以提取领域模型。但不管怎么说，我仍然坚持我自己的做法，原因有N:

1. 书上的知识是教我们思考，不是教我们教条主义的。
   说白了，一句话，书可能是对的，也可能是错的，流行的未必就是对的代名词。有个笑话曰："感冒也是流行的。"很多方法，在实际中工作得很好，但是，在理论上，就是行不通。也有很多方法，在理论上是可行的，不过，放到现实中，就是行不通。
2. 人的思维过程，不是一个线性的过程。有时候，我们就是先想到一个简单的领域模型，而这个领域模型，就可能是我们开发过程中最重要的突破。我们没有必要去强调先后："这样是不行的，你必须先整理出需求文档，然后我再提炼领域模型。"，那么，当遇到工期紧张而要需要你仿制一个已有系统的时候，你不用这种需求逆工程，还能用什么办法？
3. 领域模型是和需求同时存在的，也如同需求一样，散落在许多人的头脑中，但需求文档在书写的过程中，极容易让人陷于细节，而领域模型，比较适合抓大放小。
4. 在需求分析过程中，我们已经在不自觉的使用领域模型了。例如，我们在描述一个需求文档时，会说到"actor打开一个订单，系统显示其所有可编辑的订单行"，这里面就隐含了"订单"，"订单行"和它们之间的关联关系，这是在我们写需求之间就已经在脑子里形成的简单模型。有了这个模型，可以在描写需求的时候，将领域模型元素做为通用的词汇表，这样就不会出现前面写"订单"，后面写"销售订单"的现象了。
5. 在实际的应用过程中，这种方法是有效的。我个人的理解，我们在需求分析做了如此多的工作，对于设计和实现人员来讲，主要就是为了传递一个统一的领域模型。（当然，对测试人员和界面设计、文档编写人员来讲也是如此，不过除了这个领域模型外，还要传递其他的东西）。也就是说，如果一个需求分析人员，在提交需求文档的同时，把自己书写文档时，脑中形成的领域模型一起提交，会取得事半功倍的效果。

闲话不多说，让我们切入正题：

领域模型，当然不只类，关联和图这么简单，但这确实也是构成领域模型的最基本元素。同时，也要注意，领域模型是系统的抽象，而不是全部，我们要在此刻建立的领域模型，只是属于架构视图的那部分。这也就是28原则中的那20%。

将系统中有价值的类，关联等提取出来，只是完成了领域建模的50%，剩下的50%，就是基于需求，对领域模型构造块的重新归类、和组织。

常采用的做法有：

• 基于业务加入关联关系的导航箭头
• 使用限定符，减少多重性。
• 清除不必要的关联
• 分类：实体，值对象和服务
• 增进职责层规划
• 区分核心领域和通用子域
• 书写领域前景文档
• 显式化隐藏概念
• 套用分析模式
  
  等等。。。。

在项目交流和需求调研过程中，你可以根据领域模型，特化出一个对象图，这样非常有助于跟业务专家的交流，并且极容易在领域模型中发现矛盾甚至错误的需求。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=899906