美文网首页
领域驱动设计理解及实践(一)——了解DDD

领域驱动设计理解及实践(一)——了解DDD

作者: 盖世云鹏 | 来源:发表于2020-10-29 17:34 被阅读0次

    首先描述下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落地实践

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

    相关文章

      网友评论

          本文标题:领域驱动设计理解及实践(一)——了解DDD

          本文链接:https://www.haomeiwen.com/subject/pkhlvktx.html