软件设计要素初探：领域建模的初步思考

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

概述###

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

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

关键点###

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

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

• 是否符合自身定位

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

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

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

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

清晰灵活的模型###

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

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

发货示例###

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

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

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

基础要素：

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

• 订单角度： 订单号，总体发货状态，发货完成时间，店铺或分店号；

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

核心要素：

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

扩展要素：

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

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

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

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

跳出技术思维###

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

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

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