一、什么是业务领域建模
业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。
二、为什么要进行领域建模
软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。实际上，CQRS就是对事务脚本和领域模型两种模式的综合，因为对于Query和报表的场景，使用领域模型往往会把简单的事情弄复杂，此时完全可以用奥卡姆剃刀把领域层剃掉，直接访问Infrastructure。我个人也是坚决反对过度设计的，因此对于简单业务场景，我强力建议还是使用事务脚本，其优点是简单、直观、易上手。但对于复杂的业务场景，你再这么玩就不行了，因为一旦业务变得复杂，事务脚本就很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。
目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达，使得复杂性治理成为可能。talk is cheap，直接上一个银行转账的例子，对事务脚本和领域模型进行比较，孰优孰劣一目了然。
三、业务领域建模的设计步骤
领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。
1. 从业务描述中提取名词；
2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合；
3. 从业务实体集合中抽象业务模型，建立问题域的概念；
4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系；
四、业务领域建模的方法
四色建模法是由 Peter Coad 发明的一种建模方法，将抽象出来的对象分成四种原型：
- moment-interval：这种对象表示那些在某个时间点存在，或者会存在一段时间的，这样的对象往往表示了一次外界的请求，比如一次询价（Quotation），一次购买（Sale），这样的对象表示的都是系统的价值所在，所以也是最重要的一类对象，一般用粉红色来表示。这样的对象一般都有一个起始时间和终止时间，以及一个唯一的标识号，用来唯一的标识这一次客户请求，比如 PolicyNo.
- Role：这种对象表示的是一种角色，往往由人或者物来承担，会有相应的责任和权利，一般一个 moment-interval 对象会关联多个 Role,比如说一次询价（Quotation）涉及到两个 Role, 询价人（Quoter）和询价的产品（Product for Quotation）, 这类对象是除 moment-interval 对象外最重要的一类对象，一般用黄色来表示。这类对象一般都有一些被 moment-interval 对象请求的操作，用来完成它们的职责。
- Party：Place or Thing, 这种对象往往表示的是一种客观存在的事物，例如：人，组织，产品，配件等等，这些事物往往会在一种 moment-interval 中扮演某个 Role, 比如某个人会在一次购买中扮演 Customer 的角色，也可以在询价中扮演询价人的角色。这类对象第三重要，所以一般用绿色来表示。这类对象一般都有 Name, Address 等属性。
- Description：这种对象一般是分类用或者描述性的对象，一般某个 Thing, Place，Party会属于某个 Description，主要用来表示一类事物，它的属性一般都是这一类事物都有的属性，这类对象一般用蓝色来表示。这类对象一般都有 type, defaultValue 等属性。
五. 领域建模指南
- 关注现实世界（问题领域）对象。
- 使用泛化（is-a）和聚合（has-a）关系来显示对象如何相互关联。
- 将您的初始域建模工作限制在几个小时。
- 围绕问题领域的“关键抽象”来组织您的类。
- 不要将您的领域模型误认为数据模型。
- 不要将一个对象（代表单个实例）与数据库表（其中包含事物的集合）混淆。
- 使用领域模型作为项目词汇表。
- 在您编写用例之前，先做一些初始域模型，以避免使用名称歧义。
- 不要指望您的最终类图精确匹配您的领域模型，但他们之间应该有一些相似之处。
- 不要在您的域模型上放置屏幕（screens）和其他GUI特定的类。
