数据架构设计就是以数据为核心，来梳理整个业务处理流程

在领域模型设计中，采用类图的形式，每个类可以通过属性来表述数据结构，又可以通过方法来描述对数据结构的处理。

基于领域的程序设计

要将领域模型映射到程序设计，最终都会落实到三种类型的对象设计：服务，实体和值对象

• 服务：服务承担两个职责，接受用户请求，执行某些操作。
• 实体：那些通过一个唯一标识字段来区分真实世界中的每一个个体的领域对象
• 值对象：它代表的是真实世界中那些一成不变的，本质性的事物

通常将业务领域模型转换为程序设计，有两种思路：贫血模型和充血模型

• 充血模型：
• 贫血模型：
  二者优劣：
  • 充血模型保持了领域模型的原貌，领域模型可直接转换成程序的设计，当领域模型随着约为变更而频繁大幅度调整时，可以比较直观的映射成程序的变更，代码修改起来比较直接。充血模型保持对象的封装性，使得领域模型在面临多态，继承等复杂结构时易于变更。
  • 贫血模型比充血模型更加简单易行。
  • 充血模型需要有更浅过的设计与协作能力。
  • 贫血模型更容易应对复杂的业务处理场景。

聚合

聚合体现的是一种整体与部分的关系。 判断聚合关系最有效的办法，就是去探讨如果整体不存在时，部分是否存在。如果不存在，就是聚合；反之则不是。 有了聚合关系，部分就被封装在整体里面，这时候就会形成一种约束，即外部程序不能跳过整体去操作部分，对部分的操作都必须要通过整体。这时，整体就成为了外部访问的唯一入口，被称为“聚合根”。

仓库与工厂

• 通常会实现一个仓库（Repository）去完成对数据库的访问
• 工厂的主要工作是通过装配来创建领域对象

问题域和限界上下文

对于复杂系统，正确的做法是将整个系统划分成相对独立的业务场景，在一个一个的业务场景中进行领域分析和建模，我们称这样的业务场景为“问题子域”，简称“子域”。这一张张的领域模型，称为“限界上下文”（Context Bound， CB）