如果说当下最热门的技术概念或架构思想，那么领域驱动设计（DDD）一定占有一席之地。

上个系列，我讲了ABP vNext框架在微服务架构下的落地思路，而ABP vNext是基于DDD思想的完整框架之一，同时DDD也是微服务架构服务拆分的主流依据。无论想学好ABP还是微服务架构，首先要理解DDD。这一系列，我就从各个概念，结合在ABP vNext中的用法详细讲解DDD。

DDD是Domain Driven Design的缩写，中文翻译为领域驱动设计。首先要明确一点，DDD是一套方法论，主要面向软件设计的方法论。学习它首先要把它从具体的实现抽离出来，也要从微服务架构的概念里抽离出来，它们是相互独立的概念。而ABP框架是DDD思想的基础落地方案之一。所以是先学思想，再学落地。

DDD的核心是领域。领域又称为问题域，是对系统业务的抽象，意在将我们的重点放在需要解决的问题本身，而不是如何实现。DDD希望为业务专家（领域专家）和研发人员（技术专家）提供一套完整高效的沟通方式，并在此基础上由他们共同建立可快速落地的系统模型（领域模型）。在此工程中，业务专家不需要去关注技术实现，技术人员应该优先把精力放在理解业务本身而不是实现的细节。

DDD的核心产出结果是领域模型，在过去无论是传统软件工程方法或是基于UML的面向对象建模，软件设计过程都会产出多个不同维度的设计图，例如类图、顺序图、流程图……。但是这样存在一个问题，因为需求不断变更，每次变化我们都要花大量时间修改多个设计图。尤其对于进度比较急项目，经常会出现代码不断修改但是设计图没有足够的时间去维护。慢慢会导致设计图和实际代码不一致甚至区别很大，那么设计图将失去意义。而在DDD的思想中，所有的领域设计，都会绘制在一个图也就是领域模型图中，相当于将过去的多个图合成一个。那么我们改代码的同时，就很容易同步去修正领域模型。

后面的章节，我将从以下几个方面来深入介绍领域驱动设计：

   1. 战略设计和战术设计

   2. 分层架构

   3. 各项概念（实体、聚合、服务、DTO等）

   4. 实现方法

END

关注我获得

更多精彩