一、引言
软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。
1、为什么要研究领域驱动设计（DDD）
1.1、 设计方法各样且代码无法反映设计
- 开发一个新功能，每一位开发人员都是基于自己的方式来进行设计功能，有的用类图、有的基于流程图，有的详细、有的粗放，更麻烦的是，大家对业务背景的理解程度完全不同，认知不同，沟通低效，很难找出设计的不合理性。
- 评审代码时，很难将其与设计对应起来，这样的代码评审也就变成了代码规范性、代码设计优雅度的评审，很难找出代码业务逻辑的问题。让代码正确的反应设计，是当时评审过程中碰到的一个更大的问题。
1.2、 业务复杂不可控
以前我们经常用三层架构（分为UI层、业务逻辑层、数据访问层），业务规则的实现，通常混杂在上层UI展现逻辑、数据库访问、缓存等各种逻辑中，分散在各个层和关联对象。通过阅读业务逻辑层的代码来还原真实的业务规则很困难，很难从代码反映其业务规则设计，并且随着软件需求变更，业务规则更加难以还原，软件复杂度将不可控。
’
2、领域驱动设计与数据中心的架构方式的复杂性对比
我们把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式，在图中是黑色的粗实线；领域驱动设计在图中是绿色的粗实线。
- 当软件在开发初期，以数据驱动的架构方式非常容易上手，但是随着业务的增长和项目的推进，软件开发和维护难度急剧升高。
- 领域驱动设计则在项目初期就处在一个比较难以上手的位置，但是随着业务的增长和项目的推进，软件开发和维护难度平滑上升。
3、软件开发 VS DDD
一般软件设计或者说软件开发分两种：瀑布式，敏捷式。
前者一般是项目经理经过大量的业务分析后，会基于现有需求整理出一个基本模型，再将结果传递给开发人员，这就是开发人员的需求文档，他们只需要照此开发便是。这种模式下，是很难频繁的从用户那里得到反馈，因此在前期分析时就已经默认了这个业务模型是正确的，那么结果可想而之，数月甚至数年后交付的时候，必然和客户的预期差距较大。
后者在此基础上进行了改进，它也需要大量的分析，范围会设计到更精细的业务模块，它是小步迭代，周期性交付，那么获取客户的反馈也就比较频繁和及时。可敏捷也不能够将业务中的方方面面都考虑到，并且敏捷是拥抱变化的，大量的需求或者业务模型变更必将带来不小的维护成本，同时，对人（Developer）的要求也必然会更高。
DDD则不同：它像是更小粒度的迭代设计，它的最小单元是领域模型(Domain Model)，所谓领域模型就是能够精确反映领域中某一知识元素的载体，这种知识的获取需要通过与领域专家(Domain Expert)进行频繁的沟通才能将专业知识转化为领域模型。领域模型无关技术，具有高度的业务抽象性，它能够精确的描述领域中的知识体系；同时它也是独立的，我们还需要学会如何让它具有表达性，让模型彼此之间建立关系，形成完整的领域架构。通常我们可以用象形图或一种通用的语言(Ubiquitous Language)去描述它们之间的关系。在此之上，我们就可以进行领域中的代码设计(Domain Code Design)。如果将软件设计比做是造一座房子，那么领域代码设计就好比是贴壁纸。前者已经将房子的蓝图框架规划好，而后者只是一个小部分的设计：如果墙纸贴错了，我们可以重来，可如果房子结构设计错了，那可就悲剧了。
4、建立领域知识(Build Domain Model)
说了这么多领域模型的概念，到底什么是领域模型呢？以飞机航行为例子：
现要为航空公司开发一款能够为飞机提供导航，保证无路线冲突监控软件。那我们应该从哪里开始下手呢？根据DDD的思路，我们第一步是建立领域知识：作为平时管理和维护机场飞行秩序的工作人员来说，他们自然就是这个领域的专家，我们第一个目标就是与他们沟通，也许我们并不能从中获取所有想要的知识，但至少可以筛选出主要的内容和元素。你可能会听到诸如起飞，着陆，飞行冲突，延误等领域名词，让们从一个简单的例子开始（就算是错误的也没关系）：
- 起点－>飞机－>终点
这个模型很直接，但有点过于简单，因为我们无法看出飞机在空中做了什么，也无法得知飞机怎么从起点到的终点，刚才我们似乎提到无路线冲突，那么如此似乎会好些： - 飞机－>路线－>起点/终点
既然点构成线，那何不：
飞机－>路线－>points（含起点，终点）
这个过程，是我们不断建立领域知识的过程，其中的重点就是寻找领域专家频繁沟通，从中提炼必要领域元素。
