要实现软件设计、软件开发在一个统一的思想、统一的节奏下进行，就应该有一个轻量级的框架对开发过程与代码编写做一定的约束。
虽然DDD是一个软件开发的方法，而不是具体的技术或框架，但拥有一个轻量级的框架仍然是必要的，为了开发一个支持DDD的框架，首先需要理解DDD的基本概念和
核心的组件。
一.什么是领域驱动设计(DDD)
首先要知道DDD是一种开发理念，核心是维护一个反应领域概念的模型（领域模型是软件最核心的部分，反应了软件的业务本质），然后通过大量模式来指导模型设计
与开发。
DDD的一般过程是：首先通过软件需求规格说明书或原型生成一个领域模型（类、类的属性、类与类之间的关系）；然后根据模式（应该如何分层？、领域逻辑
写在哪？与持久化如何交互？如何协调多对象领域逻辑？如何实现逻辑与数据存储解耦等）指导来实现代码模型。
二.为什么使用DDD
DDD能应对复杂性与快速变化：
1.从技术维度实现分层：能够在每层关注自己的事情，比如领域层关注业务逻辑的事情，仓储关注持久化数据的事情，应用服务层关注用例的事情，接口层关注暴露给前端
的事情。
2.业务维度：通过将大系统划分层多个上下文，可以让不同团队和不同人只关注当前上下文的开发。
3.时间维度：通过敏捷式迭代快速验证，快速修正。
三.DDD核心组件
1.界限上下文：首先要将大系统划分层多个界限上下文，比如大健康行业直销系统可以划分为产品、经销商、订单等几个界限上下文，每个界限上下文有自己的领域逻辑、
数据持久化、用例、接口等。每个界限上下文根据特点，具体实现方式又不同，比如有些界限上下文基本没有业务逻辑，就是增删改查，则可以使用CRUD最简单的模式；
有些界限上线文有一定的业务逻辑，但对高并发、高性能没要求，则可以使用经典DDD模式；有些界限上下文有一定的业务逻辑，而且有高性能要求，则可以使用CQRS
模式。
2.实体：有业务生命周期，采用业务标识符进行跟踪。比如一个订单就是实体，订单有生命周期的，而且有一个订单号唯一的标识它自己，如果两个订单所有属性值全部相同
，但订单号不同，也是不同的实体。
3.值对象：无业务生命周期，无业务标识符，通常用于模式实体。比如订单的收货地址、订单支付的金额等就是值对象。
4.服务：无状态，有行为，通常就是一个用例来协调多个领域逻辑完成功能。
5.聚合：通常将多个实体和值对象组合到一个聚合中来表达一个完整的概念，比如订单实体、订单明细实体、订单金额值对象就代表一个完整的订单概念，而且生命周期是
相同的，并且需要统一持久化到数据库中。
6.聚合根：将聚合中表达总概念的实体做成聚合根，比如订单实体就是聚合根，对聚合中所有实体的状态变更必须经过聚合根，因为聚合根协调了整个聚合的逻辑，保证一致性。
当然其他实体可以被外部直接临时查询调用。
7.服务：协调聚合之间的业务逻辑，并且完成用例。
8.仓储：用于对聚合进行持久化，通常为每个聚合根配备一个仓储即可。仓储能够很好的解耦领域逻辑与数据库。
9.工厂：用于创建复杂的领域对象，能够将领域对象复杂的创建过程保护起来。
QQ讨论群：309287205
DDD实战进阶视频请关注微信公众号：