进行领域建模的方式是有多种的，设计出好的模型，需要大量的经验和思考。用例分析法是其中最常见分析方法。

用例

用例，英文名称Use Case，是对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术，简单来说是用来描述需求的流程。它是面向最终的用户还有领域专家的，需要由业务人员与开发人员一起创造，同时也是面向对象和面向设计的。

在1986年，Ivar Jacobson，UML和RUP（统一软件开发过程）的重要贡献者，提出了用例的概念。所以用例也是UML规范中的一种标准化的需求表达方式，RUP是以用例来驱动。

正式的用例应该包括：用例名、概述、范围、级别、主参与者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等等。并不是所有的场景都需要描述完整的用例信息，不同的侧重，可取其中不同部分来组成完整的方法。

用例图

用例图（use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

用例图并不是画成了图形的用例。用例图包含一组用例。每一用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其他系统。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。

总的来说，用例图能纲领性地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示。

在需求分析方法中的一个完整的用例应该至少用到五个部分，每个用例都将提供一个或多个场景来说明系统如果与用户或其他系统的交互：

用例把系统看作"黑盒"，同系统的交互，包括系统的响应都是可以在系统外部感知的。把细节省略到合适的细节级别，不涉及到特定的语言与实现。

大致可以分为获取用例、收集实体、添加关联、添加属性、模型精化几个步骤，中间三步也就是领域建模的三字经：找名词、加属性、连关系。

获取用例：从问题域提取领域规则描述，形成一系列需求文字描述的用例集合。
收集实体：也叫寻找概念类，识别名词和名词短语，定位实体。无论是概念还是概念的组成属性都可以提取出来。此步识别出核心域、子域、实体、值对象、领域服务，尤其是界限上下文。
添加关联：两个实体间用动词关联起来，找到模型的关联。这儿指的关联是那些需要被记住的关系，不影响业务也不需要显性表示的就不需要建立关联。
添加属性：将提取的名词、实体再次归类，把一部分名词变成实体的属性。这步只需要关注业务的概念，技术上的概念不应关注。
模型精化：可选的步骤，完善领域模型更多的信息，如划分子领域或对实体进行组合泛化等。这步需要反复迭代，直到确认模型满足业务，完整并有利于复用可扩展。

对业务领域的划分应该有一个明确的界限，这一步是基本前提，也并非要一步成型。另外一个重要的是识别用例的参与者，也就是角色，其与系统的交互也是模型分析的关键要素。

分析的过程，可以使用的工具有流程图，包图，用例图，类图，序列图或活动图等。