领域模型与建模
领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发。
两个前提：
- 大多数软件项目中，主要的焦点应该是领域和领域逻辑；
- 复杂的领域设计应该基于模型。
本系列文章主要是阅读《领域驱动设计–软件核心复杂性应对之道（修订版）》–Eric Evans 书笔记。
模型
模型：被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。它是对现实现的解释——把与解决问题密切相关的方面抽象出来，而忽略无关的细节。
模型：是浓缩的知识，是团队一致认同的领域知识的组织方式和重要元素的区分方式。
为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系。所需的知识的广度可能令人望而生畏。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。领域模型 是对这类知识严格的组织且有选择的抽象。
领域
每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。
领域是一个组织所做的事情及所其包含的一切。通俗地说，领域就是组织的业务范围和做事方式，也是软件开的目标范围。
领域建模：出于某种目的而概括地反映现实，并不是尽可能建立一个符合 “现实” 模型。
领域模型
领域模型可成为软件项目通用语言的核心。该模型是一组得自于项目人员头脑中的概念，以及反映了领域深层含义的术语和关系。同时将团队沟通与软件实现紧密联系在一起。
领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现，也就是说，设计好了领域模型对象也就设计好了业务逻辑实现。
与事务脚本被称作为贫血模型对应的，领域模型被称为充血模型。
对于复杂的业务逻辑实现来说，使用领域模型模式更有优势。
在 DDD 中，领域模型对象也被称为实体，每个实体都是唯一的，具有唯一标识。一个订单对象是一个实体，一个产品对象也是一个实，订单ID 和 产品ID 是它们的唯一标识。实体可以发生变化，比如订单状态会变化，但是它们的唯一标识不会变化。
实体设计是DDD的核心所在。首先通过业务分析，识别出实体对象，然后再通过相关的业务逻辑设计实体的属性和方法。这里最重要的是把握实体的特征，实体应该承担职责以及不应该承担的职责，分析的时候要放在业务场景和限界上下文中，而不是想当然地认为这样的实体就应该承担这样的角色。
事实上，并不是领域内的对象都应该被设计为实体，DDD推荐尽可能将对象设计为 值对象。
比如住址这样的对象就是典型的值对象，建在住址上的房子可以被当作一个实体，但住址仅仅是对房子的一个描述。像这样只是用来做度量或描述的对象应该被设计为值对象。
值对象的一个特点是 不变性，一个值对象创建后就不能被改变了。如果一个地址改变了，那就是一个新地址。
软件的核心
软件的核心：是为用户解决领域相关的问题的能力。所有其他特性，不管有多么重要，都要服务于这个基本目的。
有效建模的要素
- 模型和现实的绑定
- 建立了一种基于模型的语言
- 开发一个蕴含丰富知识的模型
- 提炼模型
- 头脑风暴和实验
大型软件项目失败
如果你对自己要开发的业务领域没有清晰的定义和边界，没有设计系统的领域模型，而仅仅跟着所谓的需求不断开发功能，那么一旦需求来自多个方面，就可能发生需求冲突，或随着时间推移，前后功能也会发生冲突，这时你越是试图弥补这些冲突，就越会陷入更大的冲突之中。
