领域驱动设计精粹（上）
概述
概念可以简单描述某类事物，这类事物可以是实体也可以是问题。领域驱动设计是为了管理系统复杂性问题而生的一套方法论。
随着业务系统的复杂性不断提高，系统的性能和灵活性要求也会越来越高，如何构建一个扩展性强、可用性高的业务系统是需要我们不断思考的问题。
我们以交易系统为例，在互联网之初，实体商业占据绝对主导地位的时代，电子商务系统最初的目的就是把货物卖出去，业务需求很简单，就是一手付钱，一手交货，而更多的难点是在于如何让人们接受并认可在网络上进行交易。随着这几十年的发展，电商早已不是最初的样子，需求变为如何更快更多的把商品卖出去，于是产生出了层出不穷你算不清楚的促销活动，比如满减、凑单、会员价、拼团、优惠券等。你买东西的价格也许只有系统能真正算清楚。
系统的复杂性比起最初，呈几何倍的增长，如何控制并管理系统复杂度是我们需要在业务发展过程中需要解决的问题。复杂的业务各有各的复杂，而拆解之道也各有各的侧重，今天要介绍的是领域驱动设计如何帮助我们拆解需求，并建立一个灵活性高、可扩展的业务系统。
领域驱动设计在讲什么
领域驱动设计中的领域是什么？我理解的是一个比行业更加细分的方向，比如互联网做电商业务是电商领域，电商中有专注交易的交易领域，做电子支付叫支付领域。领域范围可大可小，领域知识表示某些具有相关相关性知识的合集。
领域驱动设计是通过领域知识构建的领域模型来控制业务的复杂性，通过领域模型反映领域知识，构建更易维护的系统。解决软件难以理解，难以演化的问题。
上面的总结涉嫌鸡生蛋蛋生鸡的问题。其实领域模型和领域知识是迭代产生的，随着人类抽象总结而不断凝练而成的。拿之前讨论过的例子来说，一个电商领域专家可能脱口而出订单的概念，大家先入为主的很容易理解这个概念。
从人类历程来看最早出现的是物物交换的概念，后面逐渐变成等价货币交换，我们抽象的名词叫交易，再到后面你从我这里付一笔钱，我给你一个凭据，过段时间你来取货，我们管这叫购买凭据，进而逐渐演化成订单这个概念。
领域驱动设计的核心价值
领域驱动设计的核心目标是基于特定业务范围，通过统一业务概念（统一语言），将系统参与各方整合在一起，从而减少不同角色和环节的信息熵减问题。
领域模型是领域驱动设计的核心产出，它不仅能描述真实的业务逻辑和业务场景，也是系统实现的表达方式。领域模型的适应性能直接反应系统的扩展性上，能否使系统在增大时仍然保持敏捷。
领域驱动设计之所以更加流行，很大因素是领域驱动设计提供的方法论上与近些年流行的微服务有很好的匹配性，通过领域驱动设计方法清晰地识别业务边界，以此来指导微服务的拆分。 领域驱动设计提供的领域划分方法可以指导我们对微服务的拆分，以及对于演进式架构有很强的助力。
领域驱动设计的适用场景
通过上面对于领域驱动设计的介绍，可以提炼出三个主要作用：
- 统一通用语言，降低不同角色间的沟通成本。
- 通过战略设计划分子域、限界上下文，以此垂直拆解复杂度。
- 通过聚合的方式进行建模，以此水平拆解复杂度。
通过以上三个作用来逐步介绍领域驱动设计的适用场景。
多角色协作的业务场景
领域驱动设计中引入领域专家角色，是指对某个领域的概念和流程有着深入理解的一类人。开发人员与领域专家之间，他们掌握的知识存在巨大的差异。就比如电商领域专家清楚地了解交易单、订单、子单、售后、物流单、运单这些概念的准确含义，而开发人员更专注技术的运用，在沟通中如果没有达成一致的理解，沟通效率就会很差，甚至产生误解。
领域驱动设计提出从需求中提炼出统一语言，其实就是在两个不同的语言世界中进行正确翻译的过程。在多角色协作的场景中可以有效降低沟通成本，迭代式的探索和发现模型。
复杂业务场景进行业务拆解
上面我们提到现代电商促销方案层出不穷，决定一笔交易的金额有很多影响因素，而算价结果直接影响到这笔交易的支付金额，以及每件商品的实付金额。如果我们认为促销价格计算和交易联系很紧密就把他们放到了一起去开发维护，我想这个系统后面必定会难以维护，最终进行拆分。
而系统拆分的指导思想就是我们耳熟能详的六个字：『高内聚，低耦合。』 领域驱动设计有着一套完整的方法论，指导我们对复杂问题进行拆分、梳理各个子系统间的关系，帮助我们落地复杂系统。