业务团队新开发模式

2019独角兽企业重金招聘Python工程师标准>>>

现状及问题

• 需求传递效率低，需求评审效率低，缺乏业务全景图和全链路需求图，小需求也需要众人评审
• 重复建设较多，团队协同效率低，根据康威定律系统架构和组织架构会互为影响
• 难以深耕，技术实现成本较高，疲于应付新需求，各端都难以深耕和精细化运作
• 运营支持效率低，接口重复开发，数据异构且成孤岛，难以支撑业务及数字化运营
• 业务间缺乏隔离，QA测试成本较高，系统耦合封闭，很难拿出部分功能快速支持业务创新和试错

新开发模式

• 需求结构化，提供通用描述语言，并对需求进行结构化管理
• 业务可视化，业务具备可视化能力，可表现出系统具备的业务能力
• 引擎架构，做到以不变应万变，构建稳定业务内核
• 提效业务吞吐，从局部技术开发效率提升变为提升全局业务开发效率

核心关键词：

• 平台：概念开发框架，公共协作平台
• 业务技术映射：DDD，代码结构化，标准映射
• 引擎式架构：抽象原子指令，构建执行引擎，涉及表达切面

DDD解决的问题

将业务描述统一语言，将业务描述语言和技术要素之间做互相映射，划定需求界限上下文，不同研发团队负责具体界限上下文之内的需求迭代，产生服务和具体功能模块。 界限上下文之内，以领域方式进行系统分层和对象职能分配，领域内包含：

• 接口层
• 应用服务层
• 领域模型层
• 基础设施层

领域模型层：

• 值对象
• 实体
• 领域服务
• 聚合
• 领域事件
• 工厂
• 资源库

业务描述和技术要素映射

业务组成：业务规则，业务流程，业务活动

业务规则： 映射的结果是规则的表达，Domain.Service，Entity.validator等校验器，谓词判断等。

业务流程： 进行流程编排DSL，技术组件可以通过Builder工厂模式实现。

业务活动： 业务逻辑映射到领域模型，通过Entity，Value Object，Domain Service，Factory构造复杂对象，实现对数据和行为的映射。

引擎式架构

梳理并解决问题域，解空间。

将系统能力进行接入抽象，抽象为“数据物料”接入，数据物料包括：营销资源，匹配策略，定制规则，管控策略等。 系统能力扩展抽象成接口或插件扩展，比如新的营销资源，新的匹配规则，展示层定制配置，协同营销策略等都抽象为数据或者表达式。

通过数据，表达式，插件（接口）完成整个营销能力的接入，配置和扩展。 配置即数据，规则即数据，资源即数据。 系统不变的内核就是整个分层次的引擎系统，灌输不同的数据就具备不同的能力。

平台组成

• BDF开发框架
• 开放协作平台

整个平台由开放规范，业务概念抽象，BDF开发框架，开放协作平台组成。

BDF开发框架：

解决代码结构化，业务可视化，业务身份识别，业务隔离，监控，问题诊断等问题。

业务需求由多种业务能力编排而成。 业务能力由规则组合而成。 规则由数据+行为组合而成。 多种业务能力属于一种角色。 针对于角色内的扩展定制扩展点。

业务可视化分析定制能力 -> 自动生成需求PRD能力 -> 业务SDK自动生成能力 -> QA自动回归测试能力 -> 自动虚拟隔离部署能力 -> 自动数据业务运营能力

通过可拔插组件管理和对已有组件扩展实现开发扩展能力

RD根据SDK定制开发沉淀出新的业务组件，定制化SDK

解构口诀

• 语法和语义解耦
• 语义和执行解耦
• 执行和引擎解耦
• 引擎和平台解耦
• 平台和业务解耦
• 算法和结构解耦

转载于:https://my.oschina.net/u/1000241/blog/3055249