zoukankan      html  css  js  c++  java
  • 软件设计要素初探:领域建模的初步思考

    “软件设计要素初探” 一文,尝试从软件设计的整体角度,综合讨论了软件设计的各种要素。本文对领域建模作一个初步的思考。

    概述###

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

    领域建模是离代码实现最远的一层,却是软件设计中尤为重要的一环。它涉及到对现实事务、规则、流程的理解和清晰准确的提炼。在做领域建模时,切忌过早思考技术的实现。

    关键点###

    领域建模关键在于:定义自身的定位,定义基础要素,定义完备的能力集合。常常需要作出取舍。取舍的因素有:

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

    • 是否符合自身定位

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

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

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

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

    清晰灵活的模型###

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

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

    发货示例###

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

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

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

    基础要素:

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

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

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

    核心要素:

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

    扩展要素:

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

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

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

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

    跳出技术思维###

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

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

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

  • 相关阅读:
    IDEA插件之 CodeGlance(无需滚动的代码地图)
    【翻译】面向自然语言处理的深度学习(一)
    如何估算神经网络参数占用多少内存或显存容量
    Latex向上向下取整语法 及卷积特征图高宽计算公式编辑
    自动测试LeetCode用例方法
    C# Wpf 文件保存对话框
    YOLO实践初探
    前中后序递归遍历树的体会 with Python
    Python 中日期函数
    Tensorflow Windows安装
  • 原文地址:https://www.cnblogs.com/lovesqcc/p/9500887.html
Copyright © 2011-2022 走看看