现状及问题
- 需求传递效率低,需求评审效率低,缺乏业务全景图和全链路需求图,小需求也需要众人评审
- 重复建设较多,团队协同效率低,根据康威定律系统架构和组织架构会互为影响
- 难以深耕,技术实现成本较高,疲于应付新需求,各端都难以深耕和精细化运作
- 运营支持效率低,接口重复开发,数据异构且成孤岛,难以支撑业务及数字化运营
- 业务间缺乏隔离,QA测试成本较高,系统耦合封闭,很难拿出部分功能快速支持业务创新和试错
新开发模式
- 需求结构化,提供通用描述语言,并对需求进行结构化管理
- 业务可视化,业务具备可视化能力,可表现出系统具备的业务能力
- 引擎架构,做到以不变应万变,构建稳定业务内核
- 提效业务吞吐,从局部技术开发效率提升变为提升全局业务开发效率
核心关键词:
- 平台:概念开发框架,公共协作平台
- 业务技术映射:DDD,代码结构化,标准映射
- 引擎式架构:抽象原子指令,构建执行引擎,涉及表达切面
DDD解决的问题
将业务描述统一语言,将业务描述语言和技术要素之间做互相映射,划定需求界限上下文,不同研发团队负责具体界限上下文之内的需求迭代,产生服务和具体功能模块。 界限上下文之内,以领域方式进行系统分层和对象职能分配,领域内包含:
- 接口层
- 应用服务层
- 领域模型层
- 基础设施层
领域模型层:
- 值对象
- 实体
- 领域服务
- 聚合
- 领域事件
- 工厂
- 资源库
业务描述和技术要素映射
业务组成:业务规则,业务流程,业务活动
业务规则: 映射的结果是规则的表达,Domain.Service,Entity.validator等校验器,谓词判断等。
业务流程: 进行流程编排DSL,技术组件可以通过Builder工厂模式实现。
业务活动: 业务逻辑映射到领域模型,通过Entity,Value Object,Domain Service,Factory构造复杂对象,实现对数据和行为的映射。
引擎式架构
梳理并解决问题域,解空间。
将系统能力进行接入抽象,抽象为“数据物料”接入,数据物料包括:营销资源,匹配策略,定制规则,管控策略等。 系统能力扩展抽象成接口或插件扩展,比如新的营销资源,新的匹配规则,展示层定制配置,协同营销策略等都抽象为数据或者表达式。
通过数据,表达式,插件(接口)完成整个营销能力的接入,配置和扩展。 配置即数据,规则即数据,资源即数据。 系统不变的内核就是整个分层次的引擎系统,灌输不同的数据就具备不同的能力。
平台组成
- BDF开发框架
- 开放协作平台
整个平台由开放规范,业务概念抽象,BDF开发框架,开放协作平台组成。
BDF开发框架:
解决代码结构化,业务可视化,业务身份识别,业务隔离,监控,问题诊断等问题。
业务需求由多种业务能力编排而成。 业务能力由规则组合而成。 规则由数据+行为组合而成。 多种业务能力属于一种角色。 针对于角色内的扩展定制扩展点。
业务可视化分析定制能力 -> 自动生成需求PRD能力 -> 业务SDK自动生成能力 -> QA自动回归测试能力 -> 自动虚拟隔离部署能力 -> 自动数据业务运营能力
通过可拔插组件管理和对已有组件扩展实现开发扩展能力
RD根据SDK定制开发沉淀出新的业务组件,定制化SDK
解构口诀
- 语法和语义解耦
- 语义和执行解耦
- 执行和引擎解耦
- 引擎和平台解耦
- 平台和业务解耦
- 算法和结构解耦