前言

简单整理一下领域模型。

正文

领域模型是对领域内的概念类或现实中的对象的可视化表示
领域模型也称概念模型、领域对象模型和分析对象模型
领域模型是可以在业务建模科目中创建的制品之一
领域模型是up业务对象模型的特化。

领域模型在软件设计图的关系:

一开始是梳理需求，写出用例文本，建立用例模型。

然后领域模型是业务模型的一环，领域模型通过用例模型抽取出概念类、术语、概念、属性、关联。

当在业务模型中建立了领域模型之后，反过来丰富了用例模型，多了些操作契约。多了契约操作的话，那么可以以此来编写顺序图。

在uml中，领域模型被描述为一组没有定义操作的类图。

值得注意的是领域模型不是在设计阶段，不要带软件中的设计或者数据库设计。

现实中的思想，事务或者对象。关注现实世界，而非软件对象。

领域模型创建的步骤:

1. 寻找概念类
2. 绘制UML类图
3. 加关联属性

如果寻找概念类?

1. 重用修改现在的模型
2. 常见分类列表
3. 名词短语(从详述用例)

什么是概念类:

概念类是思想、事物或对象。更正正式地讲，概念类可以从其符号、内涵和外延来考虑。

举个例子:

领域模型和数据模型是一回事吗？

1. 领域模型不是数据模型(持续化数据)
2. 在领域模型中不会排除没有明确要求记录其相关信息的类，也不会排除没有属性的概念类
3. 在领域内充当纯行为角色，而不是信息角色的概念类也是有效的

动机: 降低与oo建模之间的表示差异

例如:

面向对象开发者在创建类时收到真实世界领域的启发

因此，涉众所设想的领域与其在在在软件的表示之间的表示差异被降低。

准则： 像地图绘制者一样思考：使用领域术语

1. 使用地域中现有的名称。在图书馆模型中，将顾客命名为"借书者"、"赞助者"等，这是图书管理员使用的术语
2. 排除无关或超出范围的特性
3. 不要凭空增加事物

准则： 如何对非现实世界建模

1. 有些软件系统的领域与自然领域或业务领域几乎没有类似指出，例如：电信软件
2. 此时需要高度的抽象，对常见的非00设计进行回顾，并认真汲取领域专家所使用的核心词汇和概念
3. 例如，电信软件的候选概念类：消息、连接、端口、会话、路由、协议

准则： 属性与类的常见错误

常见错误： 把应该是概念类的事务表示属性
判别准则： 如果我们认为某概念X不是现实中的数字或者文本，那么x可能是概念类而不是属性。

准则： 何时使用"描述"类建模

描述包含描述事物的信息：如productDescription 记录Item的价格、图片和文字描述。

命名方式：项目-描述符

1. 描述有关商品或服务的描述，独立于任何商务或服务现有实例
2. 删除所描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误低于所删除的事务关联起来
3. 减少冗余或重复信息

关联:

关联是类之间的关系，表示有意义和值得关注的连接。

在uml中，关联被定义为"两个或多个类之间的语义联系"，涉及这些类元实例之间的连接。

观点：关联是否在软件中实现

1. 在领域建模中，关联不是关于数据流、数据库外键的联系、实例变量或软件方案的对象连接语句；
   关联声明是针对现实领域从纯概念角度看有意义的关系
2. 这些关系的大部分作为导航(设计模型和数据模型中的)和可见性路径再软件中加以实现。

结

下一节顺序图