此次工程实践课题为软件打包与分发渠道调研与实践。下面将以工程实践项目为例，在深入理解需求的基础上进行业务领域建模Domain Modeling。
1、首先明确什么是Domain Modeling
领域建模是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。业务对象模型（domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。我们设计一个系统，总是希望它能解决一些问题，这些问题总是会映射到现实问题和概念。对这些问题进行归纳、分析的过程就是领域建模（这个域，指的就是问题域），现实世界中系统所要解决问题的领域为“问题域”，如“学生成绩查询业务”属于“教学的问题域”。
2、为什么要进行Domain Modeling
想像一下，如果您的团队中的每个人都在说不同种类的语言。假设你说德语，你的同事说法语，别的同事在说希伯来语。每次有人发言，其他人都“收获了什么东西”，然后点点头，貌似他们已经完全理解了。其实他们走进了一个完全错误的解释，这不是发言者真正想表达的话。在几乎所有IT项目中，沟通不畅的问题都很“猖獗”，但是人们却很少注意到，因为每个人都认为他们使用相同的“语言”，其实根本不是。比如：一个人说“书评”（book review），有些人将其解释为“编辑评论”（editorial review“由编辑小组撰写的评论），而其他人可能将其解释为“客户评论”（“customer review”由客户撰写的评论，并发布到现场）。结果经常是灾难性的，因为系统在开发的过程中，每个人都会以不同的方式解释需求和设计。
领域模型是一个灵活的，协作的”工做组件“。它对整个项目进行了细化和更新，从而反映了目前对“问题空间（或需求空间）”的理解。
通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象。并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。经典的面向对象的分析或调研的步骤，是把一个相关的领域，分解为单个领域类或者对象（是一个我们能够理解的概念）领域模型是领域类或者是我们感兴趣的现实对象的可视化表示。它们也被称之为：概念模型、领域对象模型、分析对象模型等。
在UML中，领域模型是不定义操作（方法）的一组类图来说明，它主要表达：1)领域对象或者领域类2)领域类之间的关联3)领域类的属性.
3、Domain Modeling步骤
1) Collect application domain information
– focus on the functional requirements – also consider other requirements and documents
2) Brainstorming
– listing important application domain concepts – listing their properties/attributes – listing their relationships to each other
3) Classifying the domain concepts into:
– classes – attributes / attribute values – relationships
• association, inheritance, aggregation
4) Document result using UML class diagram
4、工程实践的业务领域建模
1) 收集应用程序域信息，关注功能需求，同时考虑其他需求和文档
（1）软件打包
（2）软件分发到各个渠道
（3）软件发布到网站，用户下载安装包
2)列出重要的应用程序域概念
开发人员是一个实体对象
用户是一个实体对象
软件包是一个领域对象，开发人员打包发布软件包，用户进行下载
3)将领域概念分为：类–属性/属性值–关系
| 类 | 属性 | 方法 |
| Developer | Company,name | 打包软件，分发软件 |
| SoftwarePackage | size，function，label | 软件运行，软件更新 |
| User | Id | 下载软件包 |
4)使用UML类图记录结果
