领域建模的初步思考

概述

领域建模是软件设计的初始点。 反复追溯事物的本质“是什么”,从不同视角去理解事物的性质,理解事物之间的关联,梳理事物与活动的流程与环节,抽象出实体与关联,规则与约束。

领域建模最核心的部分是:定义自身的定位,定义基础要素,定义完备的能力集合。常常需要作出取舍。取舍的因素有:

  • 是否符合企业战略发展的需要

  • 是否符合自身定位

  • 是否是解决痛点所要关注的属性

  • 是否能融入到一个更大的设计里

  • 核心要素、基础要素还是扩展因素

领域建模也需要积极拓展看问题的视角,从产品、业务、客服、运营、线上线下等多角度去看待事物,充分发现其丰富的内涵。

发货示例

举交易发货为例。什么是发货?直观的理解,就是将商品送到指定的消费者手中,既是过程也是一种结果。那么交易发货关注什么呢?订单的总体发货状态及商品的发货内容及状态。商家关心订单的总体发货状态,因为涉及到订单结算;消费者关注商品的发货状态,因为涉及到合乎心理预期的商品消费。交易发货更多关心的是结果;而过程则是物流平台去关心的,运输工具、具体配送过程等。

接下来,交易发货有哪些形式? 将商品送到消费者手中,可以通过实体包裹的形式,可以通过扫码核销的形式,可以通过上门自提的形式。交易发货主要有实体包裹和虚拟核销两种形式。而在一个大的交易系统体系里,往往已经有现成的核销组件了,不期望发货去重复核销组件已经做好的事情,因此,交易发货更多关注实体包裹发货的形式。这是“从更大的设计视角中对领域因素进行取舍”的例子。

再接下来,交易发货有哪些内容呢?有整包发货、拆包发货、批量发货、分销发货、周期购发货、送礼发货、第三方配送、传送门等等,看上去发货有很多花样,那么发货的核心概念包含哪些?其中有哪些基础要素,有核心要素,以及哪些扩展因素呢? 这是领域模型关注的问题。 一个设计优雅的系统,必定含有一组核心概念集合,这些概念之间存在紧密的联系。

基础要素:

  • 商品角度: 商品ID, 商品名称,商品数量,商品类型,商品发货状态、发货期数、商品所在的包裹号;

  • 订单角度: 订单号,总体发货状态,发货完成时间,店铺或分店号;

  • 包裹角度: 包裹号,发货方式,配送时间,配送状态,配送金额,快递信息(快递公司、快递单号等),配送信息(配送公司、配送费用等); 包裹维度是多个商品发货的打包组合视角。

核心要素:

  • 订单号、商品ID及名称、商品数量、商品发货状态、订单发货状态、发货完成时间、订单对应的包裹号列表及对应的发货摘要信息。

扩展要素:

  • 发货人姓名及联系方式、配送员姓名及联系方式、配送的其他信息(重量、运输工具等)、收货人经纬度等等。

发货的完备能力集合包括:创建和变更发货计划(时机由业务方指定)、核心发货接口(支持多种配送方式和发货方式)、查询发货详情、更新发货详情、确认收货、延长收货。

交易发货作为发货业务方与物流平台的承上启下的中间层,需要借助物流平台的能力,来解决发货业务方的痛点问题,因此需要深入理解发货业务方的关注点,并将其合理地纳入到交易发货的领域模型中。

领域模型应该是可重构和演进的,不是一成不变。这意味着初期设计不必过于面面俱到,而是留下设计扩展的余地。

底层模型应清晰灵活

底层模型应当定义清晰,不依赖业务方。比如订单通用搜索API,不应当依赖业务方传来的字符串,而是根据交易核心业务,定义所需要的查询维度以及每个查询维度的取值。业务方按照这个定义来传参数。底层模型清晰,也更有益于提供稳定高可用的服务。

底层模型也应当注重灵活性。比如业务方可能只需要按照一个指定订单类型来查询订单,但是订单搜索API接口的订单类型参数却不能限于单个值,而应当提供指定多个订单类型列表来查询订单,应对未来之需。餐饮订单就是三种订单类型的统称。参数设计更灵活还有意外的好处。比如统计不同订单类型的数量,只要传多个订单类型,获取到ES结果后进行分组聚合。

超越技术思维

当拿到需求时,第一时间想到的是不是实现需求的技术方案和手段,而没有对需求里涉及的领域概念进行深入思考?技术同学习惯于从技术角度去思考问题的解决方案,设计、开发和实现。谈及设计,言必架构。事实上,技术创新和架构设计皆源于现实。深入认识现实中的变化发展,理解事物的性质和规律,理解用户的痛点,或更明白技术的价值,以及综合使用技术和非技术结合的方式去解决现实中的难题。当思维从技术架构上移到领域建模,或可催生新的思路和做法,带来新的设计。

领域建模的首要是概念萃炼。需求从何而生?所涉及的领域是什么?所涉及的基本概念有哪些?这些概念之间的关联是怎样的?这些概念所对应的实体及关联将如何变化?设计首要的工作是在概念层面精思细虑。

《领域驱动设计》上谈到,优秀的开发人员往往专注于架构、设计和基础设施的建设,却将领域模型的构建和实现交给初级工程师去完成。结果可能是,架构和设计比较优雅,可业务逻辑实现得不佳,用户得到的体验也不够好,优秀的设计没有产生有效的现实影响力。 因此,优秀的开发人员也应当重视领域建模。

猜你喜欢

转载自www.cnblogs.com/lovesqcc/p/9500887.html