h5网站建设+北京,网站开发费用如何账务处理,抖音广告推广怎么收费,注册360建筑网公司前言 正如领域驱动设计之父 Eric Evans 所著一书的书名所述#xff0c;领域驱动设计#xff08;Domain Driven Design#xff09;是一种软件核心复杂性应对之道。 在我们解决现实业务问题时#xff0c;会面对非常复杂的业务逻辑。即使是同一个事物#xff0c;在多个子业务…前言 正如领域驱动设计之父 Eric Evans 所著一书的书名所述领域驱动设计Domain Driven Design是一种软件核心复杂性应对之道。 在我们解决现实业务问题时会面对非常复杂的业务逻辑。即使是同一个事物在多个子业务单元下代表的意思也是不完全一样的。比如「商品」这个词在商品详情页语境中是指「商品基本信息」在下单页语境中是指「购买项」而在物流页面语境中又变成了「被运送的货物」。 DDD 的核心思想就是让正确的领域模型发挥作用。所谓「术业有专攻」DDD 指导软件开发人员将不同的子业务单元划分为不同的子领域在各个子领域内部分别对事物进行建模来应对业务的复杂性。 一、重构优惠中心的背景 我们在实际的开发过程中都遇到过这种情况最初因为业务逻辑比较单一为了快速实现功能 以及对成本、风险等因素的综合考虑我们会为业务统一创建一个大的模型各个模块都使用这同一个模型。但随着业务的发展各子领域的逻辑越来越复杂对这个大模型的修改就会变成一种灾难有时明明是要改一个 A 子领域的逻辑却莫名其妙影响到了 B 或者 C 子领域的线上功能。 优惠中心就是一个例子。优惠中心主要负责马蜂窝各业务线商品的优惠活动管理以及计算不同用户的优惠结果。「商品管理」和「优惠管理」作为两个不同的业务单元在初期被设计为共用一个商品模型由商品模块统一管理。 图1 初期商品模型 出现的问题 随着业务的发展优惠的形式不断推陈出新业务形态逐渐多样业务方的需求也越来越个性化导致后期的优惠中心无论从功能上还是系统上都出现了一些具体的问题 1. 功能上来说不够灵活 优惠信息是作为商品信息的一个属性在商品管理模块配置的。比如为了引导用户使用 App 需要设置 A 类型优惠就通过在商品信息的编辑页面增加一个 A 类型优惠配置项实现如果某个商品的 A 类型优惠需要在 0:00 分生效业务同学就必须在电脑前等到 0:00 更新商品信息来上线优惠活动。 另外如果想要创建针对所有商品都适用的优惠按照之前的模式所有的商品都要设置一遍这几乎是不可接受的。 2. 从系统层面看不易扩展 优惠信息存储在商品信息中优惠信息是通过商品管理模块的接口输出的。如果要新增一种优惠类型商品信息相关的表就要增加字段商品的表会越来越大如果要迭代一个优惠的逻辑就有可能影响到商品管理模块的功能。 3. 不利于迭代 由于优惠信息仅仅作为商品的一个属性没有自己的生命周期所以很难去统计某一次设置的优惠的投入产出比从而指导后续的功能优化。 重构优惠中心的预期 系统层面上要把优惠相关的业务逻辑独立出来单独设计和实现 应用层面上优惠中心会有自己的独立后台负责管理优惠活动也会有独立的优惠计算接口负责 C 端用户使用优惠时的计算。 二、分什么选择 DDD 避免贫血模型 基于传统的 MVC 架构开发功能的时候Model 层本质上是一个 DAO 层业务逻辑通常会封装在 Service 层然后 Controller 通过调用 Service 层来完成对外的功能。这种模式下数据和行为分别被割裂到了 Model 和 Service 两层。我们把这种只承载数据但没有业务行为的 Model 称为「贫血模型」。 我们在和业务方了解需求的过程中使用到的对象都是现实业务的映射是行为和属性的综合体。需求确定好之后我们开发的过程中人为把行为和数据拆分成了两部分做了一次转换。随着需求的迭代人员的更迭开发看到的代码和业务方的需求越来越对应不上导致很多代码谁也不知道对应的是什么业务逻辑这种现象被称为由贫血模型带来的「失忆症」最终导致的是一个维护成本极高的大泥潭系统。 领域驱动设计的核心就是基于业务逻辑去建模避免贫血模型减少设计和开发过程中对业务信息的丢失和转换。在业务逻辑迭代的过程中系统通过调整对应的业务模型就可以完成迭代。 三、落地过程 关键点业务逻辑抽象 要做到基于业务逻辑建模就要合理地抽象。因为业务表象千差万别产品经理和软件设计人员需要和业务专家深入交流并且从离散的信息中抽象出业务内在的逻辑。 比如旅游业务售卖的商品和标品不同有些优惠是不考虑人群的比如使用优惠券所有类型的库存都可以享受但如 N 人 N 折这类优惠成人价可以享受儿童价和单房差就不可以。基于这个特点我们对优惠中心的商品模型做了抽象抽象出来「是否可以参与件数计算」和 「是否可以参与价格计算」两个通用属性。这样既实现了基于业务逻辑建模又不会陷入业务逻辑千差万别的表象中。 3.1 战术设计 第一步统一语言提炼关键词 准确的语言对于产品、运营、开发等各方对齐需求非常重要我们需要将优惠逻辑当中的概念抽象为各方都能理解的词语以达成共识。作为开发人员来说对领域的理解一般来说是比较少的为了抽象出合理的语言让产品和业务方都能理解就需要充分理解业务背景和需求。在熟悉业务和需求的过程中提炼出若干关键字这些关键词就是最初产生的领域概念和通用语言。比如 优惠类型表示一种优惠规则和对应的优惠方案。比如早鸟优惠就是早多少钱买优惠规则减多少钱/打几折优惠方案; 优惠活动拥有完整的生命周期需要包含时间、平台、人员、商品等限制维度的某种优惠类型的使用过程信息 优惠发现根据指定的商品、人员和平台找出可以使用的优惠活动列表服务 优惠计算根据指定的商品、人员、平台以及购买数量计算出这一次购买行为可以享受的优惠金额及优惠明细 优惠排序各种优惠类型在计算的时候是有先后顺序的如果有打折的优惠存在那顺序不同计算的结果也会不同 优惠互斥某些优惠之间存在互斥的关系比如使用了金卡 96 折优惠就不能使用马蜂窝优惠券。 第二步抽象领域模型 根据单一职责的原则一个领域概念对应一个领域对象。领域对象有实体和值对象之分 实体实体是有状态的和唯一标识的包含属性和行为 值对象值对象是无状态的是只读的包含属性和行为。 区分实体和值对象对系统设计有很大意义实体是我们需要重点关注和设计的而值对象则只使用它的「值」就可以了。这样可以简化系统的复杂度将精力聚焦在核心领域对象。不难理解优惠活动毋庸置疑是一个实体优惠类型就是一个值对象。 但也存在某些业务行为是不能归于某个实体或值对象的可以将它们归为领域服务 领域服务领域服务本质上就是一些操作不包含状态通常用于协调多个实体。实体和值都属于领域对象领域对象之间的交互逻辑不能放在领域对象内部必须由服务来实现从而有效地保护领域模型。 有一些领域逻辑比如「优惠排序」和「优惠互斥」他们涉及到多个优惠类型也就是多个领域对象。如果也被设计为领域对象就打破了单一职责的原则所以我们把这部分跨多个领域对象的业务逻辑放到「领域服务」层。 第三步抽象领域对象之间的关联关系 将相关联的领域对象进行显式分组来表达整体的概念也可以是单一的领域对象也就是「聚合」。 比如优惠活动是优惠类型、优惠范围等的聚合优惠类型是优惠规则和优惠方案的聚合优惠规则是限制维度的聚合优惠方案是优惠手段的聚合 图2 关联关系示意 聚合的主要功能是把领域对象分组外部的唯一访问点就是聚合根这样可以避免处理领域对象间的一一对应关系只需要处理聚合和聚合之间的关系就行了。 第四步走查场景调整领域模型 领域模型的调整是贯穿整个设计和开发过程的随着业务的调整领域模型也需要调整。比如优惠中心后期引入了会员卡的优惠类型那么就需要把优惠券这个优惠类型的显示调整为与会员卡互斥的优惠券和与会员卡不互斥的两种。 第五步简化设计降低系统复杂度 建模的本质是对现实事物的一种简化和抽象指导我们忽略和问题域无关的事实提取和问题域息息相关的信息。以优惠中心为例最初的方案里我们设计了优惠类型管理的功能根据不同的优惠规则和优惠方案自动组合成不同类型的优惠类型。但是可以预见未来的优惠类型是有限的并且每个优惠类型都有会自己的特殊配置比如 N 人优惠里的 每 N 人/第 N 人早鸟中的提前 N 天等。也就是说根据优惠规则和优惠方案自动生成优惠类型基本是没有使用场景的因此也就去掉了这个设计。 再如对优惠的限制我们最初是设计在优惠活动维度经过权衡为了降低系统复杂度最后实现在了优惠类型层面。以「蜂抢」优惠类型为例它的规则是所有的蜂抢活动都是 1 个用户只能抢一次没有必要把这个限制放在优惠活动维度在优惠类型层面控制就可以了。 3.2 战略设计 战略设计处理的是不同限界上下文之间的拆分和集成逻辑。限界上下文比较抽象结合我们在文章开始提到的不同语境中的「商品」例子来理解同一个词如果不说明白所处的语境是无法准确描述清楚其表达的含义的。「语境」其实就是「上下文」对应不同「子领语」。同理如果不在一个限定好的上下文中去设计领域模型设计出的领域模型是不清晰的它就会同时支持多个上下文。 这里需要说明一点如果是从零搭建一个全新的电商系统首先需要做的应该是战略设计。而优惠中心是建立在现有大的电商系统基础上相当于作为其中一个子领域进行重构所以我们才会先来做战术设计再考虑在完整的电商系统下它与外部其他环境之间的关系也就是战略设计。 优惠中心内部场景区分 优惠中心包括了服务于 B 端用户的优惠活动管理和服务于 C 端用户的优惠计算这两个不同的子业务单元 、 图3 优惠中心内部场景区分 优惠活动处理的是优惠活动的增删改查以及配套的统计等业务优惠活动在这里是一个实体有完整的生命周期有上线、下线等状态可以被创建和删除 优惠计算处理的是一个订单能享受哪些优惠并减多少钱的问题在这个场景里优惠活动是一个值对象只提供优惠计算需要的必要参数即可。 优惠中心与外部系统集成 在整个电商系统的环境下优惠中心作为一个子域处于自己的限界上下文当中。使用优惠中心服务的详情页、下单页都处于自己各自的限界上下文所以调用优惠中心的时候就需要设计它们之间的上下文映射方式。 调用和被调用方使用的战略设计方法通常有以下几种 客户方-供应方适用于同一个团队之间的协作上游会有严格的自动化测试来保证给到下游的数据是一定符合约定的 遵奉者适用于不同团队协作且上游不关心下游的标准下游又完全「逆来顺受」地接受了上游给的数据的场景 防腐层适用于上游不关心下游的标准但是下游不甘心「逆来顺受」就增加一层来做转换处理保持下游系统的独立性 开放主机服务适用于中台通用能力平台对接方非常多业务重复度高并且已经有完善的测试机制和通用的模型。 结合我们的实际情况来看调用优惠中心的可能会是不同团队的开发人员而优惠中心又不想被不同的上游侵入内部设计中所以「客户方-供应方」和「遵奉者」模型都不适合另外优惠中心前期接入方会比较少而且会不断迭代使用「开放主机服务」也不太合适。综合考虑下防腐层的设计比较适合优惠中心。 下图是优惠中心的业务架构示意中间的应用服务层采用的就是防腐层的设计反映优惠中心与外部系统集成时的上下文映射关系 图4 优惠中心业务架构 3.3 架构实现 优惠中心选择的是经典的分层架构。从上到下为用户接口层、应用服务层、领域层和仓储层。图中不同的颜色块分别对映外部服务、应用服务、领域服务、聚合根、实体、值对象和仓储。 图5 优惠中心分层领域模型 用户接口层处理和终端用户的交互逻辑 应用服务层负责封装和转换领域层的返回数据给用户接口层 领域层优惠中心的核心逻辑都在这一层包括领域对象和领域服务。 仓储层仓储层负责把内存中的领域对象落地到存储介质也负责从存储介质拿到原始数据后构造领域对象给领域层使用这一层对领域层隐藏了底层的存储细节。虽然仓储层处在领域层下方但是我们实现过程中采用了依赖注入的方式将仓储层的具体实现注入到领域层中。 四、问题及近期规划 1. 价格层优惠 现在公司面没有一个统一的商品中心并且各业务线对商品的定义差别很大。比如自由行的商品包括出行日期、价格类别成人价、儿童价和套餐类别等层级而火车票的商品包含座次、席别、目的地和出发地等层级。 如果优惠中心抽象出一种通用的商品层级来适配各个业务线那实际上就是优惠中心要对商品进行标准定义但是这个标准与后续商品中心的标准定义很有可能是不一致的如果不一致优惠中心就要做大的改版。所以最终的解决方案可能还要通过推进统一商品中心的建立来解决。 2. 性能问题 领域驱动设计带来的弊端就是类的增多。目前优惠中心的技术栈基于 PHP PHP 是一种解释型语言在DDD 模式下即使有了 OPCode 等缓存技术执行阶段的耗时相对其他静态数据类型的语言还是较大。所以后面计划将优惠中心使用 Java 技术栈重构来进行性能上的优化。 五、小结 本文介绍了马蜂窝电商优惠中心基于 DDD 进行重构的一些实践经验。DDD 的思想也帮助我们在业务迭代的过程中将架构设计得更加合理。 当然是否采用业务驱动设计的思想需要取决于业务和团队的实际情况。在马蜂窝业务的快速发展下我们在架构设计上还将做更多的探索也将持续与大家交流。 本文作者徐兴旺马蜂窝电商研发平台服务团队技术专家。 马蜂窝技术原创内容转载务必注明出处保存文末二维码图片谢谢配合。 转载于:https://www.cnblogs.com/mfwtech/p/11176947.html
