1，Layered Architecture (分离领域)
1，将领域模型相关的代码集中到一个层中，把它从用户界面、应用和基础设施代码中分隔开来。
2，领域对象将重点放在如何表达领域模型上，而无需考虑自己显示和存储问题，也无需管理应用任务等内容。
3，每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。
2，关联设计
关联在领域设计中非常重要，在现实中有大量“多对多”关联，其中很多关联天生就是双向的，在早期进行头脑风暴探索领域时，也会得到很多这样的关联，但这写普遍的关联会使实现和维护变得很复杂。所以关联的设计可以遵循如下的一些原则：
关联 尽量少。对象之间复杂的关联容易形成对象的关系网，对于理解和维护单个对象很不利，同时也很难划分对象与对象之间的边界；另外，减少关联有助于简化对象之间的遍历；
关联尽量保持单向的关联；
在建立关联时，需要挖掘是否存在关联的限制条件。如果存在，那么最好把限制条件加到关联上，往往这样的限制条件能将关联化繁为简，即将多对多简化为1对多，或将1对多简化为1对1。
3，实体（Entity）
实体就是领域中需要 “唯一标识” 的领域概念。因为我们有时需要区分是哪个实体：有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，也认为他们是两个不同的实体。
不应该给实体定义太多的属性或行为，而应该寻找关联，将属性或行为转移到其他关联的实体或值对象上。比如：Customer 实体，有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以我们可以定义一个 Address 对象，然后把 Customer 的地址相关的信息转移到 Address 对象上。如果没有 Address 对象，而把这些地址信息直接放在 Customer 对象上，然后对于一些其他的类似Address的信息也都直接放在Customer 上，会导致 Customer 对象很混乱，结构不清晰，最终导致它难以维护和理解。
4，值对象（Value Object）
并不是每一个事物都必须有一个唯一标识。就以上面的地址对象 Address 为例，如果两个 Customer 的地址信息是一样的，我们就会认为这两个 Customer 的地址是同一个。用程序的方式来表达就是：如果两个对象所有属性的值都相同，我们会认为它们是同一个对象，那么就可以把这种对象设计为值对象。
值对象的特征：
值对象没有唯一标识 ，这是它和实体的最大不同。值对象在判断是否是同一个对象时是通过它们的所有属性是否相同，如果相同则认为是同一个值对象。在区分是否是同一个实体时，只看实体的唯一标识是否相同，而不管实体的属性是否相同。
值对象是不可变 的，即所有属性都是只读的，所以可以被安全的共享。
应该给值对象设计的尽量简单，不要让它引用很多其他的对象。值对象只是一个值，类似（int a = 3）中的“3”，只不过是用对象来表示。值对象虽然是只读的，是一个完整的不可分割的体，但是可以被整个替换掉：类似（a = 4）把a的值由“3”替换为为“4”，当修改 Customer 的 Address 对象引用时，不是通过 Customer.Address.Street 这样的方式来修改属性，可以这样做：Customer.Address = new Address(…)。
5，领域服务（service）
领域中的一些概念不太适合建模为对象（实体对象或值对象），因为它们本质上就是一些操作、动作，而不是事物。这些操作往往需要协调多个领域对象。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。DDD认为领域服务模式是一个很自然的范式用来对应这种跨多个对象的操作。一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。
领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作，需要了解每个领域对象的业务功能，以及它可能会与哪些其他领域对象交互等一系列领域知识。这样一来，领域层可能会把一部分领域知识泄露到应用层。对于应用层来说，通过调用领域服务提供的简单易懂且意义明确的接口肯定也要比直接操纵领域对象容易的多。
说到领域服务，还需要提一下软件中一般有三种服务：应用层服务、领域服务、基础服务。从以下的例子中可以清晰的看出每种服务的职责：
应用层服务
获取输入（如一个Json请求）
发送消息给领域层服务，要求其实现转帐的业务逻辑
领域层服务处理成功，则调用基础层服务发送Email通知
领域层服务
获取源帐号和目标帐号，分别通知源帐号和目标帐号进行扣除金额和增加金额的操作
提供返回结果给应用层
基础层服务
按照应用层的请求，发送Email通知
6，模块（Module 也称为Package）
如果说模型讲述一个故事，那么模块就是这个故事的各个章节。
1，将相关领域模型提炼分类，分而治之
2，将高关联度的模型分组到一个模块以提供尽可能大的内聚（以能完整完成任务为准）
3，分层是水平划分
4，模块是垂直划分(Domain内部)
7，聚合及聚合根（Aggregate，Aggregate Root）
聚合定义了一组具有内聚关系的相关对象的集合，以及对象之间清晰的所属关系和边界，避免了错综复杂的难以维护的对象关系网的形成。我们把聚合看作是一个修改数据的单元。
聚合有以下特点：
每个聚合有一个根和一个边界：根是聚合内的某个实体；边界定义了一个聚合内部有哪些实体或值对象；
聚合根是外部可以保持对聚合引用的唯一元素，负责与外部其他对象打交道并维护自己内部的业务规则。聚合内部的对象之间可以相互引用，但是聚合外部如果要访问聚合内部的对象时，必须通过聚合根开始导航，绝对不能绕过聚合根直接访问聚合内的对象；
聚合内除根以外的其他实体的唯一标识都是本地标识，也就是只要在聚合内部保持唯一即可，因为它们总是从属于这个聚合的；
聚合内部的对象可以保持对其他聚合根的引用；
删除一个聚合根时必须同时删除该聚合内的所有相关对象，因为他们都同属于一个聚合，是一个完整的概念；
基于聚合的以上概念，我们可以推论出从数据库查询时的单元也是以聚合为一个单元，不能直接查询聚合内部的某个非根的对象；
如何识别聚合：
可以从业务的角度分析哪些对象它们的关系是内聚的，可看成一个整体来考虑的，然后这些对象可以放在一个聚合内。关系内聚是指这些对象之间必须保持一个固定规则，固定规则是指在数据变化时必须保持不变的一致性规则。当修改一个聚合时，必须在事务级别确保整个聚合内的所有对象满足这个固定规则。聚合尽量不要太大，否则可能带来一定的性能问题。通常在大部分领域模型中，有70%的聚合通常只有一个实体，即聚合根，该实体内部没有包含其他实体，只包含一些值对象；另外30%的聚合中，基本上也只包含两到三个实体。
如何识别聚合根：
如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。
8，工厂（Factory）
DDD中的工厂也是一种体现"封装思想"的模式。DDD中引入工厂模式的原因是：有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。工厂是用来封装创建一个复杂对象尤其是聚合时所需的知识，将创建对象的细节（如何实例化对象，然后做哪些初始化操作）隐藏起来。
客户传递给工厂一些简单的参数，如果参数符合业务规则，则工厂可以在内部创建出一个相应的领域对象返回给客户；但是如果参数无效，应该抛出异常，以确保不会创建出一个错误的对象。当然也并不总是需要通过工厂来创建对象，事实上大部分情况下领域对象的创建都不会太复杂，只需要简单的使用构造函数就可以了。隐藏创建对象的好处：可以不让领域层的业务逻辑泄露到应用层，同时也减轻了应用层的负担，它只需要简单的调用领域工厂创建出期望的对象即可。
9，仓储（Repository）
仓储被设计出来的原因：领域模型中的对象自从创建后不会一直留在内存活动，当它不活动时会被持久化到DB中，当需要的时候会重建该对象。所以，重建对象是一个和DB打交道的过程，需要提供一种机制，提供类似集合的接口来帮助我们管理对象。
仓储里存放的对象一定是聚合，因为之前提到的领域模型是以聚合的概念来划分边界的。我们 只对聚合设计仓储 ，把整个聚合看成一个整体，要么一起取出来，要么一起被删除，不会单独对某个聚合内的子对象进行单独查询和更新。仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，在领域模型中定义仓储的接口，而在基础设施层实现具体的仓储。
参考：《领域驱动设计》 Eric Evans [美]
