领域模型驱动

几乎每种语言、开发框架和工具面世时，都号称要把开发人员解放出来，让他/她们更加关注于业 务逻辑的处理。但目前的工作状况是，每当一个新的“解放工具”出现，就会有众多的技术狂热者蜂拥而上，而忽略了他们最应该关注的业务逻辑部分。还好，从 2004年开始，“领域驱动设计”的声音开始浮现，开始逐渐扭转这种局面。

领域驱动设计词解

尽管提出人EricEvens 已给出了领域驱动设计的官方的解释，但始终让人感觉存在一些困惑。笔者将从一个工程实践者的角度来重新对这些词做出简要的解释。

领域

Eric给出的解释是:“用户应用软件的主题区域”。那么我们应该如何理解这句话呢？例如，如果有人想把个人的社会关系写程序展现出来，类似于“我是孙向晖，我是豆豆的父亲，我是我父亲的儿子。”有多少人会感觉到这段可能出自“好玩”的程序的价值？

但是，国家正在建立个人和企业的全国征信系统，以建立信用档案，规避“我给豆爷做汽车贷款担保，豆爷给豆豆做房屋贷款担保，豆豆给我做商业贷款担保”这样的风险，这样以来，个人的社会关系就成为非常有价值的基础信息建设。

因此，软件的主题区域应该是在浩瀚的知识和客户要求(CustomerRequest)中被精心选择和摘取出来的部分，用来解决实际的业务问题。但是经常被项目研发团队混淆或者忽略的是:客户需要不一定就是有效需求。

很多团队将自己的工作重点放在了满足客户的变更需要上，结果客户满意度反而下降了。在这种情况下，这个团队更应该审视一下自己的变更控制流程，目前团队实现的是不是太多的客户需要而非有效需求呢？

一个软件涵盖的业务范围会非常的广，我们需要继续根据二八原则来进行识别，以便找出其中的核心领域作为软件开发的重点。

为了确定软件的领域，我们通常可以问如下两个问题:

1.软件实现后的核心业务价值是什么？

2.谁会为这个核心业务价值的实现来买单？

驱动

“驱动”这个词近些年来不绝于耳，耳熟能详的如:用例驱动开发 （UDD）、特性驱动开发（FDD）、测试驱动开发（TDD），驱动的本质是什么？

“驱动”就是试图让我们的思路更顺畅，场景的切换更平滑。“领域驱动设计”就是希望在我们的设计中首先体现的是核心领域的选择和实现。我们做出来的设计跟所选择的领域之间更具有可追溯性、可度量性。

领域发生了变化，领域模型和设计就要发生相应的变化;设计变化了，一定能够追溯到领域的变更。引发设计变化的因素很多，一定要是关键的领域部件所带动的。

模型

虽然，我们可以从众多的线索中抽取出比较核心的部分（也就是领域），但是领域还是太大，所以我们需要对领域的不同的侧面进行描述，以期团队成员可以很好的跟领域专家进行沟通，不至于在若干的岔路前迷失。