时代特征

不确定性和变化是这个时代的主旋律。

业务需要快速上线，并根据用户的反馈不停地调整和升级，有生命力的业务主动寻求变化，不变则亡是很多行业目前的共识，企业应对变化的响应力成了成败的关键。

鸡蛋，从里面破开，结果是生命；从外面破开，是食物。

业务开发的痛点

• 如何更好地构建软件？
  • 现有的代码我不满意，我知道它乱，但不知如何入手解决
  • 听说过业务架构整体优雅，允许局部腐化，但没见过
• 如何管理代码的复杂度？
  • 系统越来越不可控
  • 尤其是，倒排期现象不止，新PRD不断涌入
• 如何让代码成为领域知识？
  • 如何让代码反映业务？
  • 系统是否支持我以不同粒度不同视角从不同维度低成本地梳理出业务？
  • 代码如何能反应PRD的内容？
  • 如何让产品和技术间形成一致性产出物？
  • 听说过code is documentation，但什么是code is domain knowledge?
  • 代码的结构化，是什么意思？
• 如何让业务代码和技术代码解耦？
  • 业务是业务，技术是技术
  • 有的技术底座，我想用外包实现，可我是一个代码库，我也不敢相信外包质量，如何解决？
  • 我的团队，有的人明显适合业务领域开发，有的适合技术性系统开发，如何人员分层管理？
  • 想从代码里捋业务，就会变成这样：Q：“晚饭吃了啥？”。 A：“我用勺子一口一口地吃了鸡生下的蛋和番茄再加上油一起炒的菜。”
• 业务不确定，尤其是2B业务，如果有KA更惨
  • 如何优雅地解决：业务逻辑的扩展，业务模型的扩展，业务流程的扩展
  • 有些if条件，场景已经不存在了，可不敢删，因为它的逻辑散落各处
  • 某个特殊业务，我们开发了好几个月，我们如何统计这个业务特有的代码？
  • 经常有特殊创建要我加字段，甚至加表
  • 又来个新场景，流程跟之前不同。我已经使用模板方法固化流程了，这可怎么办？
  • 如何快速响应千奇百怪的个性化需求，同时保持自身不腐化
• 研发痛点
  • 如何让研发拿到需求立刻就知道代码写在哪里，不各显神通地造轮子造概念
  • 不要跟我讲各种方法论，架构思想，我只想知道这个PRD怎么好地实现：donot make me think!

业务开发的复杂性来源

业务开发，不同于技术开发：

• 业务开发：变，杂
• 技术开发：稳，深

根本来源

• 业务场景多，差异大
• 个性化需求多
• 业务术语多，每个术语可能都对应一大堆字段、逻辑和流程
• 业务流程长，任何一个节点错误都会造成整体bug
• 2B业务更严重，每个行业每个企业都有不同的业务诉求

附属来源

• 缺乏顶层设计，造成的代码随意
  • 千人千面的代码风格和设计
  • 没有顶层逻辑，没有灵魂
• 业务和技术的耦合，代码本身无法透析业务本质
• 代码质量差
• 代码自身的可解释性差
• 团队规模
• 人员流动
• 项目流动
• 交付周期

业务中台的痛点

• 中台，是企业级能力复用平台，到底什么意思
  • 什么是能力
  • 业务资产是什么，与数据资产什么关系？此外，还有哪些软资产？如何落地？
• 如何支持前台、中台协同开发，破除中台单点瓶颈，各司其职，人员解耦，开发解耦
• 到处都在讲中台，中台的代码应该长什么样？
• 前台、中台组织到底该如何分工
  • 前台做什么，中台做什么
  • 业务演化如何进行
  • 前台业务如何下沉到中台，风险如何控制
• 如何解决前、中台速率匹配问题，让中台不阻塞前台业务发展
• 中台如何实现各个前台的业务隔离，防止相互干扰？

业务开发的本源

如果能做到如下几点，业务代码质量就不会太差：

• 收敛
• 封装
• 多态
• 可读

业务开发框架现状

市场上有很多技术框架，也有一些low code甚至codeless框架来满足简单业务场景，但开源的解决复杂业务场景问题的业务开发框架，目前是空白。

中台架构，更多停留在思想和方法论上，具体在代码层面如何落地，目前是空白。

DDDplus，一套轻量级业务中台开发框架，解决了这些空白。