1：领域建模
领域建模（Domain Modeling）表示开发团队用来获取知识的过程；
2：为什么进行领域建模
因为软件工程师在不同的项目或者领域里面工作，他们需要不同领域各自的模型知识来开发系统。而且，开发工程师可能来自不同的背景，这可能会影响他们对整个系统的理解。事实上，领域模型最不同于传统模型的地方在于，领域建模下，接触到需求第一步就是考虑领域模型，也就是将需求大致划分为几个大的领域，而不是按照数据和行为对其进行分割。然后数据部分依靠数据库实现，行为操作使用服务实现，最后使得需求界限清晰明了。也就是说，领域建模首先考虑的是业务，而不是行为，不是数据。它强调业务抽象和OO编程，这和传统的面向过程式的编程有明显差别。
3：模型和领域建模
模型由元素和元素之间的关系组成，这些元素自身和关系依靠简单图形图表来描述，是一种更为简单的类图，能清晰表达元素的本质特征和各个元素模块的的之间的主要关系，领域模型下，元素之间的关系大致分为继承（Inheritance）、聚集（Aggregation）和关联（Association）三种联系：
继承（Inheritance）：表达概念之间的通用型和专业性关系，在继承关系下，通常是一方比另一方更为通用或者专业，这种关系也会称为IS-A关系；
聚集（Aggregation）：表达这样的一个事实：一个对象是另一个对象的一部分。这种关系也称为所属关系。
关联（Association）：表达两个概念之间的应用程序特定关系，比较通用和一般，既不是继承，也不是聚集。
4：如何进行领域建模：
以工程实践为例子，各个阶段的操作过程如下：
【1】收集应用程序的领域信息，比如说类和对象等等。特别集中在功能需求上，也考虑其他需求和文档。因此，首先是应该准确指出一些比较核心的概念，这些核心概念和主要业务特点可以通过和实践小组的组员讨论确定，通过协作沟通，集思广益，可以较为准确的确定一些通用而广泛的核心概念和重要业务。其他概念可以尽可能的先表述出来，深入模型底层的概念可以暂时留存在第二步通过头脑风暴的形式进一步挖掘。
抓住核心概念之后，然后再照着这些概念大致的走一遍业务场景，看看是否能覆盖到绝大多数的需求。此处采用一些伪代码，用于辅助验证概念的实用性，如果这一步没有问题，则比表示核心概念的收集和表示都是准确可行的，否则，就需要进行模型或者角度的调整。随着项目的进行和对事件逻辑的不断深入，对所建立模型的理解将愈发深入。比如说，在竞赛者提交个人解决方案的这个角度上，最开始提取的概念有竞赛者、提交语言形式、文件、时间戳、提交记录、系统评测系统以及方案评测结果。
【2】头脑风暴，建立类和对象的关系。列出重要的应用程序领域概念、他们的特点或者属性，以及它们和其他概念之间的关系。主要是在功能需求描述中寻找和列出名词或者名词短语。比如说，首先寻找“X of Y”字眼，寻找及物动词、形容词或者数词，因为它后面跟随的名词可能是对我们有帮助的核心概念。其次寻找含有所属关系的表达，比如说“**部分”的表达方式、包含或者含有的表达式以及“X is a Y”这样的表达式。
【3】对领域概念进行分类，然后添加给类添加属性等等。分类结果如下：类；属性/属性值；关系（关联，继承和聚集）。
一般是给类添加主要的数据类型和数据操作。依然以【2】中的竞赛者提交个人方案为例，个儿参赛者的单次方案的提交可以设计为提交管理领域的一个类，其中各种属性和关系阐述如下：
选手ID是一个属性，其值是能唯一标识一个选手的序号；
提交语言是一个属性，其具体值可以是计算机语言的任意一种；
提交方式是一个属性，其值可以是文件提交、在线提交、提交URL链接几种方式；
时间戳是一个属性，能唯一表示单次解决方案的提交记录，其值是一个时间记录。
评测结果是一个属性，用来表示一个解决方案提交记录的正确性，其值有true和false两种。
评测系统是一个属性，表示对应于当前方案的评测系统，根据不同的提交语言，用不同的评测系统，其值是评测系统标识号。
提交记录是一个属性，能记录下所有选手的提交时间戳，这个值包含多项信息，有选手ID、题号、提交信息、提交时间戳、提交结果。
【4】使用类图记录分类结果，即使用UML类图对领域信息进行可视化操作。
5：以工程实践，在线竞赛平台的设计与开发为例子，进行领域建模的类图结果如下：
