领域模型
领域模型是什么
领域模型，又称概念模型、领域对象模型、分析对象模型，是对领域内的概念类或现实世界中对象的可视化表示，其将结构的概念和行为的概念结合了起来。在书《UML和模式应用》中，就认为领域模型是需求分析阶段的业务模型，是一种业务概念实体的模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。领域模型构成了您的模型的静态部分的基础，而用例是动态部分的基础。静态部分描述结构;动态部分描述行为。
下面将从领域模型和业务模型之间区别的角度来举个例子对其概念加以说明。如一个读者持借书卡去图书馆借书这个场景，在业务模型中会存在一个借书卡的业务概念，而在领域模型中，我们很可能会去掉借书卡，因为它只是一个借书的工具，是借书系统用来识别读者的一个工具，系统真的的目的是为了知道哪个账号在借书，而不关心如何识别出这个账号。
（业务建模是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统）
对业务领域模型的理解
每一个复杂的软件都应该按层来组织，每一层就代表系统的一个逻辑部件。其中，抽象的讲业务逻辑层是系统的一部分，用来处理和业务相关的任务，其处在一个分层系统的中间，和表现层、数据访问层交换信息。而业务领域模型即为业务层实现一个结构化的视图。
为什么要进行业务领域建模
领域建模可以降低软件和现实世界之间的差异，用真实的业务概念划分职责，目的是实现一个可以高效低成本维护的可持续发展的软件系统。
从领域模型推导到系统实现是一套引导思考的方式，也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上，既可以用来同客户沟通验证需求，又可以避免模型因实现的考量而带偏（实现成本、遗留系统）
软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。
领域建模一般步骤
Collect application domain information
– focus on the functional requirements
– also consider other requirements and documents
Brainstorming
– listing important application domain concepts
– listing their properties/attributes
– listing their relationships to each other
Classifying the domain concepts into:
– classes
– attributes / attribute values
– relationships
• association, inheritance, aggregation
Document result using UML class diagram
工程实践的业务领域建模
Collect application domain information
首先是收集业务领域信息，我们不仅要关注业务功能要求，还需要考虑其他的要求和文件。
而我们工程实践的题目为低功耗文件系统的实现，主要应用场景为各种类型嵌入式设备，为我们的终端提供文件存取、管理等功能，具体来说有：提供文件基本操作接口、提供设备文件管理方案、提供合适的低功耗方案等。
Brainstorming
接着要根据上一步列出重要的应用领域概念以及他们的属性，还需要找出互相之间存在的关系并列出来。
操作接口：文件属性（文件ID、文件类型、文件权限），文件具体操作ID，文件具体操作功能（文件打开、文件关闭、文件读、文件写）等
文件管理：文件属性（文件ID、文件类型、文件权限）、管理类型（挂起、唤醒、入栈、出栈等）、操作所需结构（队列、链表、堆栈等）
低功耗：（接触中。。。）
Classifying the domain concepts
然后对领域概念进行分类
文件属性类、文件操作类、文件管理类
Document result using UML class diagram
最后根据以上分析制作完成类图