标签：原则 domain 内聚 取出 结构 好处 数据 不同 常用
我们所做的软件系统的目的都是来解决一系列问题，例如做一个电商系统来在线销售自己企业的产品；做一个灰度发布平台来提升服务的质量和稳定性。任何一个系统都会属于某个特定的领域，例如：
同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。因此可以推断：一个领域本质上可以理解为一个 问题域 。只要确定了系统所属的领域，那么这个系统的核心业务，即要解决的关键问题就基本确定了。通常我们说，要成为一个领域的专家，必须要在这个领域深入研究很多年才行，只有这样才会遇到非常多的该领域的问题，积累了丰富的经验。
通常来说，一个领域有且只有一个核心问题，我们称之为该领域的『核心子域』。在核心子域、通用子域、支撑子域梳理的同时，会定义出子域中的『限界上下文』及其关系，用它来 阐述子域之间的关系 。界限上下文可以简单理解成一个子系统或组件模块。
例如：下图是对酒店管理的子域和界限上下文的梳理：
领域驱动设计（Domain-Driven Design）分为两个阶段：
由此可见，领域驱动设计的核心是建立正确的领域模型。领域模型具有以下特点：
由软件专家和领域专家合作开发一个领域的模型是有必要的。开发过程中， 开发人员以类、算法、设计模式、架构等进行思考与交流。但领域专家对此一无所知，他们对技术上的术语没有太多概念，只了解特有的领域专业技能，例如：在空中交通监控样例中，领域专家知道飞机、路线、海拔、经度、纬度，他们有自己的术语来讨论这些事情。软件专家和领域专家交流过程中，需要做翻译才能让对方理解这些概念。
领域驱动设计的一个核心原则是使用一种基于模型的语言。使用模型作为语言的核心骨架，要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样，这种语言被称为『通用语言』。
『用户需求』不能等同于『用户』，捕捉『用户心中的模型』也不能等同于『以用户为核心设计领域模型』。设计领域模型时不能以用户为出发点去思考问题，不能老想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。
领域模型是 排除了人之外的客观世界模型 ，包含了人所扮演的参与者角色。但是一般情况下不要让参与者角色在领域模型中占据主要位置，否则各个系统的领域模型将变得没有差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪。例如：
以一个货物运输系统为例子简单说明一下。在用户需求相对明朗之后，这样描述领域模型：
以上描述没有从用户的角度去描述领域模型，而是以领域内的相关事物为出发点，考虑这些事物的本质关联及其变化规律的：
以用户为中心来思考领域模型的思维只是停留在需求的表面，而没有挖掘出真正的需求的本质。领域建模时需要努力挖掘用户需求的本质，这样才能真正实现用户需求。
用户界面/展示层：1）请求应用层获取用户所需的展示数据；2）发送命令给应用层执行用户的命令
应用层：薄薄的一层，定义软件要完成的任务。对外为展示层提供各种应用功能，对内调用领域层（领域对象或领域服务）完成各种业务逻辑。应用层不包含业务逻辑
领域层：表达业务概念、业务状态信息及业务规则，是业务软件的核心
基础设施层：为其他层提供通用的技术能力，提供了层间通信；为领域层提供持久化机制。
关联在领域建模的过程中非常重要，关联的设计可以遵循如下的一些原则：
实体就是领域中需要 唯一标识 的领域概念。因为我们有时需要区分是哪个实体：有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，也认为他们是两个不同的实体。
不应该给实体定义太多的属性或行为，而应该寻找关联，将属性或行为转移到其他关联的实体或值对象上。比如：Customer 实体，有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以我们可以定义一个 Address 对象，然后把 Customer 的地址相关的信息转移到 Address 对象上。如果没有 Address 对象，而把这些地址信息直接放在 Customer 对象上，然后对于一些其他的类似Address的信息也都直接放在Customer 上，会导致 Customer 对象很混乱，结构不清晰，最终导致它难以维护和理解。
并不是每一个事物都必须有一个唯一标识。就以上面的地址对象 Address 为例，如果两个 Customer 的地址信息是一样的，我们就会认为这两个 Customer 的地址是同一个。用程序的方式来表达就是：如果两个对象所有属性的值都相同，我们会认为它们是同一个对象，那么就可以把这种对象设计为值对象。
值对象的特征：
应该给值对象设计的尽量简单，不要让它引用很多其他的对象。值对象只是一个值，类似（int a = 3）中的『3』，只不过是用对象来表示。值对象虽然是只读的，是一个完整的不可分割的整体，但是可以被整个替换掉：类似（a = 4）把a的值由『3』替换为为『4』，当修改 Customer 的 Address 对象引用时，不是通过 Customer.Address.Street 这样的方式来修改属性，可以这样做：Customer.Address = new Address(…)
领域中的一些概念不太适合建模为对象（实体对象或值对象），因为它们本质上就是一些操作、动作，而不是事物。这些操作往往需要 协调多个领域对象。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。DDD认为领域服务模式是一个很自然的范式用来对应这种跨多个对象的操作。一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。
领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作，需要了解每个领域对象的业务功能，以及它可能会与哪些其他领域对象交互等一系列领域知识。这样一来，领域层可能会把一部分领域知识泄露到应用层。对于应用层来说，通过调用领域服务提供的简单易懂且意义明确的接口肯定也要比直接操纵领域对象容易的多。
说到领域服务，还需要提一下软件中一般有三种服务：应用层服务、领域服务、基础服务。从以下的例子中可以清晰的看出每种服务的职责：
应用层服务
领域层服务
基础层服务
聚合定义了一组具有 内聚关系 的相关对象的集合，以及对象之间清晰的所属关系和边界，避免了错综复杂的难以维护的对象关系网的形成。我们把聚合看作是一个修改数据的单元。
聚合有以下特点：
如何识别聚合：
可以从业务的角度分析哪些对象它们的关系是内聚的，可看成一个整体来考虑的，然后这些对象可以放在一个聚合内。关系内聚是指这些对象之间必须保持一个固定规则，固定规则是指在数据变化时必须保持不变的一致性规则。当修改一个聚合时，必须在 事务级别 确保整个聚合内的所有对象满足这个固定规则。聚合尽量不要太大，否则可能带来一定的性能问题。通常在大部分领域模型中，有70%的聚合通常只有一个实体，即聚合根，该实体内部没有包含其他实体，只包含一些值对象；另外30%的聚合中，基本上也只包含两到三个实体。
如何识别聚合根：
如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。
DDD中的工厂也是一种体现 封装思想 的模式。DDD中引入工厂模式的原因是：有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。工厂是用来封装创建一个复杂对象尤其是聚合时所需的知识，将创建对象的细节（如何实例化对象，然后做哪些初始化操作）隐藏起来。
客户传递给工厂一些简单的参数，如果参数符合业务规则，则工厂可以在内部创建出一个相应的领域对象返回给客户；但是如果参数无效，应该抛出异常，以确保不会创建出一个错误的对象。当然也并不总是需要通过工厂来创建对象，事实上大部分情况下领域对象的创建都不会太复杂，只需要简单的使用构造函数就可以了。隐藏创建对象的好处：可以不让领域层的业务逻辑泄露到应用层，同时也减轻了应用层的负担，它只需要简单的调用领域工厂创建出期望的对象即可。
仓储被设计出来的原因：领域模型中的对象自从创建后不会一直留在内存活动，当它不活动时会被持久化到DB中，当需要的时候会重建该对象。所以，重建对象是一个和DB打交道的过程，需要提供一种机制，提供类似集合的接口来帮助我们 管理对象。
仓储里存放的对象一定是聚合，因为之前提到的领域模型是以聚合的概念来划分边界的。我们 只对聚合设计仓储 ，把整个聚合看成一个整体，要么一起取出来，要么一起被删除，不会单独对某个聚合内的子对象进行单独查询和更新。仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，在领域模型中定义仓储的接口，而在基础设施层实现具体的仓储。
领域建模是一个不断重构，持续完善的过程，大家会在讨论中将变化的部分反映到模型中，从而模型不断细化并朝正确的方向走。
本文是阅读学习 汤雪华的博客 后所做的一些整理，希望能对大家有所帮助~
标签：原则 domain 内聚 取出 结构 好处 数据 不同 常用
原文地址：http://www.cnblogs.com/butterfly100/p/7827870.html
