- 上一篇：琉璃神社,琉璃神社神秘代码
- 下一篇：permission denied解决方法没有权限
建立领域知识(Build Domain Model)
说了这么多领域模型的概念，到底什么是领域模型呢？以飞机航行为例子：
现要为航空公司开发一款能够为飞机提供导航，保证无路线冲突监控软件。那我们应该从哪里开始下手呢？根据DDD的思路，我们第一步是建立领域知识：作为平时管理和维护机场飞行秩序的工作人员来说，他们自然就是这个领域的专家，我们第一个目标就是与他们沟通，也许我们并不能从中获取所有想要的知识，但至少可以筛选出主要的内容和元素。你可能会听到诸如起飞，着陆，飞行冲突，延误等领域名词，让们从一个简单的例子开始（就算是错误的也没关系）：
起点－>飞机－>终点
这个模型很直接，但有点过于简单，因为我们无法看出飞机在空中做了什么，也无法得知飞机怎么从起点到的终点，刚才我们似乎提到无路线冲突，那么如此似乎会好些：
飞机－>路线－>起点/终点
既然点构成线，那何不：
飞机－>路线－>points（含起点，终点）
这个过程，是我们不断建立领域知识的过程，其中的重点就是寻找领域专家频繁沟通，从中提炼必要领域元素。
尽管看起来还是很简单，但我们已经开始一步步的在建立领域对象和领域模型了。
通用语言(Ubiquitous Language)
上面的例子的确看起来简单，但过程并非容易：我们（开发人员）和领域专家在沟通的过程中是存在天然屏障的：我们满脑子都是类，方法，设计模式，算法，继承，封装，多态，如何面向对象等等；这些领域专家是不懂的，他们只知道飞机故障，经纬度，航班路线等专业术语。
所以，在建立领域知识的时候，我们（开发人员和领域专家）必须要交换知识，知识的范围范围涉及领域模型的各个元素，如果一方对模型的描述令对方感到困惑，那么应该立刻换一种描述方式，直到双方都能够接受并且理解为止。在这一过程中，就需要建立一种通用语言，作为开发人员和领域专家的沟通桥梁。
可如何形成这种通用语言呢？其实答案并不唯一，确切的说也没有什么标准答案。
a)UML
利用UML可以清晰的表现类，并且展示它们之间的关系。但是一旦聚合关系复杂，UML叶子节点将会变的十分庞大，可能就没有那么直观易懂了。最重要的是，它无法精确的描述类的行为。为了弥补这种缺陷，可以为具体的行为部分补充必要说明（可以是标签或者文档），但这往往又很耗时，而且更新维护起来十分不便。
b)伪代码
极限编程是推荐这么做的，这个办法对程序猿来说固然好，可立刻就要将现有模型映射到代码层面，这对人的要求也是不低，并不容易实现。
模型驱动设计(Domain Driven Design)
模型关系图(Model-Driven Design)
领域驱动设计中的模型关系图
层结构(Layered Architecture
User Interface
负责向用户展现信息，并且会解析用户行为，即常说的展现层。
Application Layer
应用层没有任何的业务逻辑代码，它很简单，它主要为程序提供任务处理。
Domain Layer
这一层包含有关领域的信息，是业务的核心，领域模型的状态都直接或间接（持久化至数据库）存储在这一层。
Infrastructure Layer
为其他层提供底层依赖操作。