一、 什么是(DDD
Domain-Driven Design
)领域驱动?DDD（Domain-Driven Design 领域驱动设计）是由Eric Evans最先提出，目的是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的，开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，这样周而复始，构建出一套符合当前领域的模型。
通俗的理解为:先构建领域模型设计，然后通过领域模型设计驱动软件架构的设计。那么什么是领域呢？
二、 什么是领域？
领域:领域并不是什么高深的知识,领域在我看来就是一个行业的划分，比如一个电商领域，肯定包含了，产品，订单，发票，物流的概念。
当我们在要开发一个大型软件系统时,这时就要将系统划分为多个子系统，这时我们对系统的划分是基于领域的，也是基于业务的。
那么哪些概念应该放在子系统中，这时便有界限上下文的概念。
三、 什么是界限上下文?
在一个领域/子域中，我们会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和领域具有一对一的关系。简单来说就比如说，将一个公司，划分为多个部门，每个部门有各自的成员，每个部门的成员负责各自部门内的任务。
四、 DDD领域驱动设计软件架构？
DDD(领域驱动设计)并不要求采用特定的架构风格，因为它是对架构中立的。你可以采用传统的三层式架构,也可以采用 eric evans的“领域驱动设计
User Interface：负责向用户展现信息，并且会解析用户行为，即常说的展现层。
Applicaiont: 应用层没有任何的业务逻辑代码，它很简单，它主要为程序提供任务处理。
Domain: 这一层包含有关领域的信息，是业务的核心 ，领域模型的状态都直接或间接（持久化至数据库）存储在这一层。
Infrastructure:为其他层提供底层依赖操作。
总结:
（DDD）领域驱动设计只是一种指导程序开发的思想，从领域驱动软件设计架构，当然运用(DDD)领域驱动设计，不是说一定要用哪种设计，当然你运用DDD(领域驱动设计)的思想，而软件架构依然采用原有的三层架构也是可以的.当然也可以采用 Eric Evans的领域驱动设计。
