首先描述下DDD的存在解决了什么问题

有限描述及强调下解决的问题，以便于更好的理解DDD，同时强调作为解决问题的初衷，有助于在做DDD设计时把控方向

先以举例说明，便于从现实角度理解：

• 背景描述：
  [此处待补图]

  • 业务量级：
    京东的店铺业务有几十种（如SOP、FBP、全渠道门店、京东到家、京东健康、新通路、整车业务等等），针对于几十种店铺，所涉及到的商家入驻阶段流程、合同签署、平台费保证金、订单计费结算、开店后的商家发品、品类精细化运营规则，优惠政策及处罚，续签、关店等等等等业务，当然除了这些，在不同的店铺业务下，每个细分业务场景都可能会有不同的逻辑处理，可以说贯穿整个电商生命周期都会有业务逻辑，并且随着市场变化，这个数量还在不断扩大。
  • 诸多角色：
    针对于庞大量级的业务形态，最终被组织架构、以及业务功能拆分之后，经常涉及到夸部门的业务联调，以计费结算举例，一笔订单，从商家开通类目，对应类目发品、用户加购物车、提交订单、支付、计费、发货、妥投、结算、逆向流程的退款、退货、逆向计费等，如此长的链条涉及到夸团队的协作，甚至是夸二级乃至一级部门间的人员就非常之多，同时又会涉及多种角色，例如店铺运营、品类运营、事业部运营、平台运营业务、产品、研发、测试等诸多角色。

• 如上场景下，描述问题：

  • 概念理解偏差：
    举例1：以新增一套结算佣金扣点举例，初期理解的诉求是类似于抖音、火山等站外推广产生的订单，定期会对不同的类目扣点进行优惠调整。后期深入后理解的诉求是，随着业务的变化，例如6.18大促、双11大促期间，或者某个特定时间节点会做优惠活动，是针对于不同的活动进行的政策调整。在没有对业务深入理解的情况下，对系统的设计可能不够全面，容易进入到误区造成理解偏差，导致设计不合理。
    举例2：关于商家入驻时签署的合同，因历史系统遗留问题，有一个字段为业务类型，实际上选择的内容是是否为主合同以及是否为电子签的组合，这对于未来系统的扩展造成了很大困难和干扰，主要原因其实就是未能对概念进行充分理解，导致后续带来难维护难扩展的问题。
  • 角色间理解偏差：
    相关参与人员要聚焦一个相同的业务进行问题处理，提供方案并落地，例如“商家的业务类型”，这个词，可能在不同部门、不同角色之间的理解是天差地别的。
  • 代码臃肿：
    传统的分层架构MVC、Service、Dao，将主要的业务集中到了Service层，这样带来的问题显而易见，当类似于上面的业务内容拥挤在这一层，即便是从组织架构层面，各部门及所担负的职责是有明确分工的，但是在单一的某个职责下，所要实现的逻辑也是非常庞大的。
  • 重构难度大，应对变化效率变低：
    业务的变化必然会带来经常性的代码变更，单纯的臃肿已经是个问题，外加复杂逻辑结构的纠缠，耦合，变成所谓的“大泥球”式的代码，维护难度加大，与快速应对变化的目标相左。
  • 传统设计思维惯性，影响对业务的理解:
    这里的传统设计思维指的是先从数据库设计角度出发，以关系型数据库为主先将业务需求第一印象的映射到库表关系上，这样已经经过了一次从业务的转化，当面对与业务频繁变化的前提，会对现有模型进行扩展，而这时数据模型先入为主将会影响到从业务角度理解概念及扩展，导致设计方向走偏。

  [此处待补图]

如上，伴随着组织架构和平台的不断扩大，业务是层出不穷的变化的，接下来将如何发展是很难预测的，而作为一线的业务、产品、研发，对现有产品的走向未知，无论是产品设计，还是系统的架构设计，无法提前预估预判。

所以在不断变化中寻找不变来尽可能的减小业务变化所带来的成本，提升效率。这里面仅是尽可能的让分析设计变得合理，这是一个不断迭代和变化的过程。

DDD是如何解决问题的

领域驱动设计的核心步骤分为如下

• 战略设计
  战略设计是从更上层的角度（按领域划分、同时伴随着公司的组织架构）来对问题进行拆分，以便于将问题聚焦，关注该关注的问题，后面会有具体的实施举例。

  1. 寻找问题域
     明确细分要讨论并解决的领域是什么，是一个范围
  2. 对领域与领域之间的协作，明确上下文关系，上下游关系
     明确领域的切分、边界，领域之间的协作关系
  3. 划分领域和子域
     划分出在对应领域下，关注的核心域，以及支撑域，通用域等
  4. 统一语言，形成通用语言
     将领域内关注的事务，明确通用词汇以及相关解释（解读），并形成文档，以约束和确立问题解决中概念的统一

  如上从现实角度出发去分析，解决了关于问题分析不够透彻导致不易扩展或设计偏差的问题，也同时约定了“紧密”相关方在问题描述中的不一致导致的理解偏差。

• 战术设计

  1. 明确问题域的范围及核心关注点后，对解决的域进行领域建模，明确聚合、实体、值对象、聚合根等模型，并尝试探索对应领域对象的自身行为（功能）、职责；
  2. 将系统架构与DDD思想进行融合，形成落地的系统结构，明确代码的隔离及依赖关系；
  3. 不断完善更新领域模型，迭代修正认知并重构落地；

  DDD落地并非一次成型，以上是一个循环的过程，因为随着问题的不断变化，业务的不断变化，认知是会发生改变的，在实践的过程中可能会推翻之前自己的理解并进行优化，==但本质是，从现实角度出发帮助我们理解业务，从业务角度如何更合理的分析问题并解决==

DDD落地实践

领域驱动设计理解及实践（二）——落地实践 编写整理中……