不管在做系统分析，还是系统设计时，我们大概率都会提到领域模型这个词，奇妙的是虽然大家都在谈论领域模型，但每个人心中都有一份对领域模型的认知。
套用DDD，我们需要统一语言，首先需要对“领域模型”有一个统一认知。达成共识。
你可以暂时挂起大脑进程，想想：“领域模型是什么？怎么描述？”
世事万物都在变化中发展，就如同“手机”，十年前和现在，人们对它的认知也是不一样的。所以我们一起回顾一下最原始的“领域模型”是什么，你是否记起大明湖畔的领域模型。
“领域模型”最早流行于OOA中，简单回顾一下OOA/D
OOA/D
分析：强调的是对问题和需求的调查研究，而不是解决方案。例如，如果需要一个新的在线交易系统，那么，应该如何使用它？它应该具有哪些功能？
设计：强调的是满足需求的概念上的解决方案，而不是实现。例如，对数据库方案和软件对象的描述。设计思想通常排斥底层或“显而易见”的细节。最终设计可以实现，而实现则表达了真实和完整的设计。
++分析和设计可以概括为：做正确的事和正确地做事++
OOA：强调在问题领域内发现和描述对象（或概念）。例如，在航班信息系统里包含飞机、航班和飞行员等概念。
OOD：强调的是定义软件对象以及它们如何协作以实现需求。例如，软件对象Plane可以有tailNumber(飞机唯一标识)和getFightHistory方法(飞行过的航班)
领域模型
领域模型是OOA中最重要的和经典的模型。
定义
领域模型是对领域内的概念类或现实世界中对象的可视化表。也称为概念模型、领域对象模型和分析对象模型。
不是描述软件类、软件架构领域层或有职责软件对象的组图。
Why
为什么需要领域模型？去掉修饰语，为什么需要模型，这在DDD系列文章中已经解释：模型是对业务复杂度的简化和提炼。帮助我们更好地理解业务。
同理领域模型能够使我们理解关键概念和业务知识。
我们在设计和实现时，软件类名称也大多源于领域模型的名称，以使对象具有源于领域的信息和职责。
这样可以降低我们思维与OO建模之间的表示差异
How
如何创建领域模型？
- 寻找概念类
- 将其绘制为UML类图中的类
- 添加关联和属性
寻找概念类
根据领域模型定义，需要先找到概念类。
概念类是思想、事物或对象。可以从其符号、内涵和外延考虑。
符号：表示概念类的词语或图形
内涵：概念类的定义
外延：概念类所适用的一组示例
考虑购买交易事件的概念类。
可以使用符号Sale对其命名。
Sale的内涵陈述为“表示购买交易的事件，并且具有日期和时间”
Sale的外延是所有销售的例子，或者说是世界上所有销售实例的集合
描述类图
领域模型描述的信息可以采用纯文本方式表示。
但是在可视化语言中更容易理解这些术语，特别是它们之间的关系，因为我们的思维更擅长理解形象的元素和线条连接。
在应用UML时，领域模型被描述为一组没有定义操作的类图。
关联
关联是类之间的关系，表示有意义和值得关注的连接。
关联能够满足当前所开发场景的信息需求，并且有助于理解领域。
关联被表示为类之间的连线，并冠以首字母大写的关联名称。
关联末端可以包含多重性表达式，用于指明类的实例之间的数量关系。
关联本质上是双向的，方向箭头只是为了方便阅读，默认是从左往右。
总结
没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近似。
领域模型主要是特定群体中用于理解和沟通的工具。
有效的领域模型捕获了当前需求语境下本质抽象和理解 领域所需要的信息，并且可以帮助理解领域的概念、术语和关系。
到此，已经完成追忆大明湖畔的领域模型，也是OO风云初起时代领域模型的含义。
如果你想更多的回忆，可以去看看以往OO方便书籍，本文内容大多来自《UML和模式应用》。
现今，领域模型演义出更多新的含义，如Martin Fowler提出的充血模型，以及DDD中的领域模型。
在与别人交流时，我们得听声听音，是否在同一频道。
