关于领域驱动（domain-driven desgin, ddd）开发 概述

关于领域驱动开发，想写一个系列的文章。分享一下近两年在项目中运用ddd的经验，和自己的一些理解，教训。

第一篇文章先概述一下。

领域驱动设计 domain-driven design. 简称ddd。

在岛国这两年是一个比较火的名词，明明是一个有着多年历史的概念，不知道为什么过了那么久突然流行了起来。天朝的情况不是很了解，不过无所谓啦，思想啦理论啦不存在国界的！

什么是ddd?

这一个概念来自Eric Evans所著的一书。（P.S. 此书极为枯燥，而且理论繁多，阅读的障碍很大。）书中并没有很正规地用下定义来描述各种名词，所以个人认为导致了对领域驱动究竟是什么的的多种解释。

在这我说一下自己的理解（仅限于自己理解）

领域（以下都称domain）指需要解决的现实问题（业务），为了解决现实问题（domain）,我们会建立模型(以下称model)来帮助我们描述与理解domain，从而能够应对domain。

纯理论地说，domain是问题空间，model是解决空间（虽然一点都不好懂）。

比如，要开发一个考勤管理系统，考勤中的一些实际业务如打卡，休假申请就是domain。我们会建立一些model来应对这些domain。比如建立休假申请的model，然后赋予它一些状态，来描述休假申请这个业务的执行。这种domain与model的对应比较简单。如何管理考勤，已经有现有的经验与管理方式，从这个意义上说帮助我们理解的抽象的model已经存在，我们只是为了软件设计的方便对model在进行加工。

但如果一些复杂的问题，domain与model的关系就会不那么一目了然，比如要评价学生是一个现实课题（domain）。那用学生的考分进行评价就是一种model。

那domain驱动设计，顾名思义，由从domain出发，来设计，建模。

而ddd的大致流程便是

1 理解domain

2 建立应对domain的model （domain model）

3 根据model开发。

另外，ddd中，model一般特指domain model。即刚才说的应对domain的model。

为什么需要ddd?

这种看似理所当然的设计方式，为什么要像当作课题一样提出呢？

1 业务(domain)的复杂性，让理所当然的事情，做起来不那么简单

 没能完成需求的项目，必定是失败的。(当然项目的失败也有可能是其他原因，这不属于ddd讨论范畴。)当domain十分复杂时，我们必须有好的方法去理清，理解domain，并根据他来开发。

2 人们设计时当然是离不开model的。但model其实也是分好几种。比如domain model（领域模型）与data model（数据模型）。

 有时候会更倾向于对data model的思考，比如拿到需求就开始搞数据表设计，并不是说data model不好或者不重要，而是跳过了domain model，直接考虑data model，容易导致建立的model没能很好的应对实际的domain。这个以后会重点讲！

3 软件的开发，纵向分工过多，每一次分工都会建立新的model来教给下层的开发人员来实现，结果导致开发人员对domain的理解不正确，最终导致产品不能实现业务。

 从前（现在也可能）的软件开发行业，存在各种外包。有的软件公司只负责设计，然后把设计文档人给其他公司编码。这种现象在岛国的软件开发行业非常常见，以至于岛国的互联网行业。。。大概的流程会是需求分析，上流设计，详细设计，编码。

综上，ddd所提倡的是，不要建立过多的model，而是建立与domain最接近的domain model，然后根据domain model来进行开发。model必须尽量反应实际的domain。

ddd真的有效吗？

这个问题非常难。。。如果你去网上搜一下ddd的成功案例。结果会是。。。（应该没有）

也有种说法是ddd所追求的是对domain model的不断深化改造，所以在应用ddd开发的人们眼里，达到什么程度算是成功是不明确的。

从本人目前的工作经验上说，有项目运用了ddd，是否实现了ddd的精髓有待商榷，但开发者有了共同的设计思想和交流语言，使设计容易传达，说了更明显一点，就是代码容易读，容易修改。但有个人觉得这种效果其实需要非常多的前提，以后的文章会进一步讨论。

另外，有时候理论是用来解决某一些特定问题的。比如ddd提倡根据domain model来开发，防止对需求的认识偏差。但如果项目开发中，开发人员的需求的理解偏差不是一个很大的问题，那ddd在这个问题上就没有太多发挥余地了（个人认为）。当然除了这个ddd当然还有其他的作用，以后会介绍。

但底线是，我们可以通过学习ddd所提倡的思想和一些设计手法，帮助我们做一些更好的设计。

今后的内容

之后会写更多ddd的内容。顺序的话并不按照domain-drive design书中的章节（比如准备先讲战术，再讲战略）。而是类似于还原自己如何去接触ddd的过程，这样可能更容易理解。对于想学习应用程序架构，程序设计的人来说，可能是一种比较自然的理解/学习过程

目前能想到的大概有

ddd的战术: 分层设计

ddd的战术: entity, VO, aggregate, repository

ddd的战术: 如果没有domian model程序会是怎样的？

ddd的战术: domain event

让ddd发挥自己的优势，CQRS！

ddd的战略: bounded context

另外列一下推荐的参考书

implementing domain-driven desgin （比较通俗易懂）

domain-driven desgin distilled

domain-driven desgin （如果你想抱着试试的态度，千万别先读这本书，过早尝试会让你对ddd的兴趣丧失殆尽）