BPAAS化建设实践-基本流程篇

本文详细阐述了BPAAS化建设的流程,包括领域划分、子域定义、领域服务与领域能力、扩展点、场景、节点、流程编排和业务身份等关键概念。此外,还介绍了DDD分层架构,强调了业务逻辑应集中在领域层,避免应用层过于庞大。最后,探讨了分层架构的作用,旨在消除信息不对称,以业务为中心进行领域划分,实现复杂业务的拆分与治理。
摘要由CSDN通过智能技术生成

前言:该篇为bpaas开发过程中整理出来的流程及遇到的一些问题,目前已成功落地,该文章为初稿,如果有什么不太理解的地方,可以留言沟通。

一、BPAAS化建设流程图

这是一个基本流程图,之间的交互细节会在之后详解。

这里需要知道的几点:

1.层级的划分

2.都经过了哪些流程

3.对象何时进行了转换

4.建立一些模糊的概念

 

 二、BPAAS名称概述

1.领域

做bpaas化系统首先要做的就是划分领域模型,将不同的内容划分到不同领域模型里面。
比如:
商品域、价格域、类目域、租户域等等

2.子域

划分子域,划分好域之后,需要对领域进行细化,将商品域划分成多个子域:sku商品域、门店商品域、商品标记域、商品关系域等等。
需要注意的点:
如果有内容定位不到该属于哪个域,就需要头脑风暴,最终讨论归属到哪个域合适。
比如:
商品域里面的门店商品,到底是归属门店商品域还是商品域还是门店域

3.领域服务

定义完领域子域后需要定义的是领域服务,领域服务就相当于一个个接口。
比如:以一个商品写领域服务来说,里面包含了新建商品领域服务、修改商品领域服务等等,是一个完整的服务。

4.领域能力

领域能力和领域服务不同的是,领域服务是领域能力聚合后的产物,每个领域能力都可以抽离出来去聚合其他的领域服务。
比如:
一个新增商品领域服务里面可能包含了入参校验领域能力、业务参数校验领域能力、构建入参领域能力,新增product领域能力、新增sku领域能力等等。

5.扩展点

每个领域能力都对应一组扩展点实现,每个扩展点的出入参数、方法名都是固定的。更像是一个接口对应了多个实现类。但里面有一个需要注意的地方,就是通过身份标识来确定进入到哪一个扩展点里面。

6.场景

场景是针对于扩展点的,对不不同场景的业务,要走不同的扩展点。
有一些复杂的场景,比如入参只有一个类目id,需要查出来它的信息才去调用商品新建的能力,这时就需要有构建的能力,将类目信息构建到商品对象中进行新建操作。但如果有业务身份不需要类目构建呢,那就需要场景图这个场景,来区分到底走哪一个构建能力里面。

7.节点

每个节点基本上是对应一个领域服务,节点将流程中的对象解析成了领域对象,用来调用领域能力。

8.流程编排

一个流程对外来说就是一个api,内部实现是通过多个节点组合起来的,
比如,一个获取商品详情的api里面涉及到的节点可能有:查询品牌节点、查询类目节点、查询广告词节点、查询商品节点,经过流程编排将这些节点聚合到了一起。不同的业务身份可能需要的节点不一样,有的可能没有广告词这个节点,就不需要将广告词节点放在编排流程。

9.业务身份

应当于saas化系统中租户的概念,不同的租户之间可能有微小的差异性,通过业务身份进行不同的流程编排和进入不同的扩展点来解决差异性问题。

10.基础设施层

基础设施层主要是放一些中间件和rpc:中间件如es、redis、db。

11.核心包

核心包中有流程编排、节点、领域服务、领域能力、定义领域对象bo。

12.水平包

水平包是在核心包外层的一个包,里面是一些扩展内容,主要有扩展点。

13.垂直包

垂直包相对于水平包来说,是只有一部分特有业务才需要的业务流程的话放在这个包内,主要也是扩展点。

三、DDD分层架构

严格分层架构:某层只能与直接位于的下层发生耦合。(MVC架构)

松散分层架构:允许上层与任意下层发生耦合。(DDD架构)

在领域驱动设计(DDD)中采用的是松散分层架构,层间关系不那么严格。每层都可能使用它下面所有层的服务,而不仅仅是下一层的服务。每层都可能是半透明的,这意味着有些服务只对上一层可见,而有些服务对上面的所有层都可见。

分层的作用,从上往下:

  • 用户交互层:web 请求,rpc 请求,mq 消息等外部输入均被视为外部输入的请求,可能修改到内部的业务数据。

  • 业务应用层:与 MVC 中的 service 不同的不是,service 中存储着大量业务逻辑。但在应用服务的实现中,它负责编排、转发、校验等。

  • 领域层:或称为模型层,系统的核心,负责表达业务概念,业务状态信息以及业务规则。即包含了该领域所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上,可以从实体,值对象,聚合(聚合根),领域服务,领域事件,仓储,工厂等方面入手。

  • 基础设施层:主要有 2 方面内容,一是为领域模型提供持久化机制,当软件需要持久化能力时候才需要进行规划;一是对其他层提供通用的技术支持能力,如消息通信,通用工具,配置等的实现。

在设计和开发时,不要将本该放在领域层的业务逻辑放到应用层中实现,因为庞大的应用层会使领域模型失焦,时间一长你的服务就会演化为传统的三层架构,业务逻辑会变得混乱。

DDD 整体作用总结如下:

  • 消除信息不对称;

  • 是MVC三层架构中自底向上的设计方式做一个反转,以业务为主导,自顶向下的进行业务领域划分;

  • 将大的业务需求进行拆分,分而治之。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值