领域驱动设计之：领域建模

一、项目的终极目标

       普通开发者在开发一个项目时，可能考虑到的都是如何实现业务逻辑，同时提高程序性能，好一点的开发者会同时考虑到代码的复用性和扩展性，没错，上面提到的几点都是一个优秀的技术开发需要必备的素质，但是如果想要真正的做出好的项目，是需要深入了解项目所属领域的专业知识，从而设计出易于维护，能够满足组织后续需求，可以不断演进的复杂软件。

二、如何实现终极目标

       很多项目最主要的复杂性往往不在技术上，而是来自领域本身、用户的活动或业务，当这种领域复杂性在设计中没有充分考虑并得到解决时，基础技术的构想再好也无济于事。所以为了达到终极目标，往往需要在项目开发前进行充分的头脑风暴和建模，通过领域模型，提升开发人员与领域专家之间的沟通质量。概括起来就是基于模型的沟通。

三、软件核心

       软件的核心是为用户解决领域相关的问题的能力，所有其他特性，不管有多么重要，都要服务于这个基本目的。

       举一个很简单的例子，假如我们有一个需求，运营人员需要一个后台去查看和管理我们的数据，目的是为了通过数据了解用户行为喜好，设计出更好的软件系统。首先我们分析下项目的核心是什么？查看和管理数据，所以数据的直观性和准确性才是软件的核心，而UI的美与丑，并不是我们需要关注的核心问题，如果我们把精力放在界面的美化上，项目周期拖长，最终会影响运营人员的工作效率。

四、如何建模

4.1 有效建模的要素

1. 模型和实现的绑定：我们的代码实现应该基于模型的设计，并且在后续的迭代中，需要持续维护模型。
2. 建立一种基于模型的语言：俗话说，隔行如隔山，当我们新接触一个项目时，在第一次和产品经理沟通中，他们不得不向我们解释最基本的概念和逻辑，而我们也必须向他们解释我们实现上的大致思路，这都是有必要的，会推送最终项目的结果趋向完美。随着项目的进展和迭代，双方都能直接使用模型中的术语沟通，无需想办法翻译成对方能够听懂的话术。
3. 提炼模型：在模型日趋完善的过程中，重要的概念不断被添加到模型中，无意义的概念则从模型中被移除，随着时间的推移，沟通会变得越来越高效。
4. 头脑风暴和实验：语言、草图、头脑风暴，是高效沟通的三要素。

4.2 知识消化

       高效的领域建模人员是知识的消化者，他们在大量信息中探寻游泳的部分，不断尝试各种信息组织方式，努力寻找对大量信息有意义的简单视图。知识消化并非一项孤立的活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队共同协作。他们共同收集信息，并通过消化而将信息组织为有用的形式。信息来自领域专家头脑中的知识、现有用户、以及技术团队在类似系统中积累的经验。

       在传统的开发流程中，业务专家对问题进行讨论，消化理解知识点，抽象成文档传递给程序员，再由程序员编写软件代码。这种方式完全没有反馈，因此结果很容易失败。即便不会失败，也会在开发的过程中反复反馈问题，调整需求设计，不仅会影响开发人员的整体构思，同时会严重影响项目周期（这个问题在我所在团队经常出现）。

       一个好的开发流程，应该是业务专家和研发人员头脑风暴共同产出的，虽然这种形式 表面看似会浪费很多时间在开会沟通上，但往往在这个过程中会暴露出很多设计中的问题，同时可以过滤掉一部分非核心的问题，强化核心问题。

4.3 持续学习

       项目所在领域的知识往往分散在不同的文档中， 其中夹杂着一些无关的信息，因此可能我们并不知道哪些是我们需要的知识。看似没有什么技术难度的领域很可能是一种错觉，我们并没有意识到自己不了解的东西究竟有多少，很可能错过了关键核心。高效率的团队要有意识地积累知识，并坚持对所在领域进行学习，对于开发人员既要完善技术知识，也要培养领域建模技巧。

4.4 策略封装

       所谓策略封装，是指的将一些单独的逻辑封装成函数块，后续规则的更改无需影响核心流程代码。比如我们的订单评论系统，我们最初的策略是只对结束的订单展示评价（将来可能对订单展示对规则进行调整），假如我们订单结束的状态是4000，一般开发写的程序可能是下面这样：

if ($order->status == 4000){
    showComment();
}

       好的代码 往往如下：

if ($orderIsShow($order)){
    showComment();
}


function isShow($order)
{
    return $order->status == 4000;
}

五、总结

       领域知识需要不断学习和抽象，知识消化是一种探索，对领域模型的完善永无止境！