业务领域建模Domain Modeling

　　模型(Model)通常由2部分组成： 
　　　　1）元素(Element) 
　　　　2）（元素间的）关系(Relationship)

　　想像一下，如果您的团队中的每个人都在说不同种类的语言。假设你说德语，你的同事说法语，别的同事在说希伯来语。每次有人发言，其他人都“收获了什么东西”，然后点点头，貌似他们已经完全理解了。其实他们走进了一个完全错误的解释，这不是发言者真正想表达的话。在几乎所有IT项目中，沟通不畅的问题都很“猖獗”，但是人们却很少注意到，因为每个人都认为他们使用相同的“语言”，其实根本不是。比如：一个人说“书评”（book review”），有些人将其解释为“编辑评论”（”editorial review“由编辑小组撰写的评论），而其他人可能将其解释为“客户评论”（“customer review”由客户撰写的评论，并发布到现场）。结果经常是灾难性的，因为系统在开发的过程中，每个人都会以不同的方式解释需求和设计。领域模型是一个灵活的，协作的”工做组件“。它对整个项目进行了细化和更新，从而反映了目前对“问题空间（或需求空间）”的理解。在本文中，我们将介绍领域建模，其目的是通过建立映射问题空间的常用词汇来解决项目沟通不畅的问题。

　　

十大领域建模指南：

　　1.关注现实世界（问题领域）对象。

　　2.使用泛化（is-a）和聚合（has-a）关系来显示对象如何相互关联。

　　3.将您的初始域建模工作限制在几个小时。

　　4.围绕问题领域的“关键抽象”来组织您的类。

　　5.不要将您的领域模型误认为数据模型。

　　6.不要将一个对象（代表单个实例）与数据库表（其中包含事物的集合）混淆。

　　7.使用领域模型作为项目词汇表。

　　8.在您编写用例之前，先做一些初始域模型，以避免使用名称歧义。

　　9.不要指望您的最终类图精确匹配您的领域模型，但他们之间应该有一些相似之处。

　　10.不要在您的域模型上放置屏幕（screens）和其他GUI特定的类。

　　创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织您的软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，您将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。

 

我的工程实践为手写文本行识别。以我的工程实践为基础，进行领域建模的步骤如下：

（1）发现类及其属性，区分业务主体、实体、属性、实例

（2）将各个名次归类，分到相应的问题域。

（3）确定模型之间的关系，用UML提供的方法和图例进行领域模型设计，关键是找准关系以及对应的映射关系（多重关系  1 对 1，  1 对 多，多对多）。

最后类图如下：