中台、领域设计

中台的理解

https://www.zhihu.com/question/57717433
王健老师在《当我们谈中台时，我们在谈些什么| 白话中台战略》一文中提到的关于中台的一些理解

中台概念 是相对于 烟囱概念 而设计的

• 在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
• 在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
• 在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。

中台更多是因为公司业务在发展到某一阶段时，遇到瓶颈与障碍后，为解决实际问题而提出的解决方案。

借着移动互联网的红利，许多公司都高速发展，进行大规模业务拓展，业务拓展的速度足够快，对公司自然是好事，但是随着而来的问题就是，公司内部出现了大量的重复建设和资源浪费的现象。比如阿里：淘宝，后来意识到B2C模式的天猫，10年又上线1688、聚划算等业务，需要用到的系统功能也高度类似，主要也是订单、商品、库存、价格、仓储、物流等系统。阿里内部将共享服务部的职权不断提升，统一将各个业务业务部门重复使用，反复建设的功能和系统统一规划和管理。

阿里供应链中台/图源网络

再比如滴滴的各种业务也都很类似。

两类问题，在软件开发领域，有专门的名称，叫做“重复造轮子”和“烟囱式架构”。

一类是，许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。
另一类是，早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。

但是，当你需要响应多个业务部门的时候，就没有那么容易了。
你会发现，同样一个需求，A部门的流程和B部门流程完全不同，或者，流程是相似的，但到具体细节的时候，却有很大差异。更可怕的是，同样一个问题，由于业务的发展阶段不同，对于问题的态度也全然不同：有的部门业务已经非常成熟，自己流程也很清晰，所以不太希望你来调整他们现有的流程；但是，有的部门还处于探索期，还没有遇到你提出的问题，可能压根就不理你。这时，对于中台产品经理的挑战就非常大。
他们可能会将大量的精力耗散于不同部门之间的沟通协调，反复对同一个需求进行确认，很长时间没有明显突破。这个时候，就要求中台产品经理有很强的沟通、协调和协作能力。并且，因为他们接下来要做的解决方案，是要服务于多个业务。这个时候，需要中台产品经理有很强的逻辑思考能力，看到不同需求之间的共性需求，并提炼出一个产品化的解决方案。
这又很要求产品经理的逻辑思考和抽象思考能力。

---

中台实质就是一个业务产品工厂，可以通过“配置大于研发的约定”快速构建业务前台，这对应了超级细胞SuperCell的各种游戏。

总结下对中台的一些理解：

• **中台的意图：**让业务更好的进行创新、试错，同时大大降低新业务研发成本。
• **中台的理论基础：**前台只是一层皮（这层皮也不仅仅是前端，还可以包括后面的前台领域系统），基础设施只是一套没血肉的骨架，位于中间的看不见的血肉才是软件系统的核心，如果这些血肉每次都要重建，那么将严重阻碍新业务创新、试错的速度。
• **中台的方法论：**和平台方法论并无差异——抽象通用能力+开放设计，这两者比例多大，不好说，这里也不想耍流氓那样用个二八定律去糊弄大家，相信不同的业务场景这个比例多少会有些不同。
• **中台的本质：**四个字——系统复用。复用也分层次，也有复用程度之分，通过抽象出各种配置来支撑定制化这件事的本质也是复用——复用配置系统。
• **中台的实施原则：**专注领域复用能力建设、配置大于研发。这个点看似很简单，但是极具艺术性，配置如何做到化繁为简很关键，如果发现配置复杂度比研发还大，那就瞎了。

中台的理念一定是没错的，只是要因地制宜，切忌一刀切。比如像阿里这样全集团都中台化。

笔者建议，中台的建设应当围绕单一职责的领域能力去构建，单一能力又可以提供一些简单配置来实现定制化使用（就像一款款的中间件那样），比如我们只需要申请好支付账号和密钥，就可以在系统里集成支付宝了。在这些可以复用的系统能力至上，我们再去定制化构建自己的前台业务系统。

阿里云业务中台：

业务中台技术架构图

可以解决的问题

• 将企业核心能力下沉共享，加速企业创新速度
• 规范IT全生命周期管理，提升研发效率与质量。减少重复建设和资源浪费
• 提供行业最佳实践，助力企业快速落地中台战略

其他概念–分层设计和领域划分

浅谈微服务体系中的分层设计和领域划分

我们主张将其Web服务架构分为五层：基础设施层、领域服务层、应用服务层、网关层和用户界面层（表示层）
贫血模型、充血模型、领域模型

贫血模型 VS 充血模型

确实是这样，DDD和面向对象、设计模式等等理论有千丝万缕的联系，如果不熟悉OOA、OOD，那么DDD可能也会理解不了。因为我们大部分从开发生涯开始之初接触的都是「Action层、Service层、Dao层、DB层」这样的MVC分层理论。并且在21中设计模式中，「行为型」的设计模式，我们几乎没有什么机会使用，导致这些问题的原因是J2EE经典分层的开发方式是「贫血模型」。

Martin Fowler(对，就是提出微服务的那位大牛)曾经提出了两种开发方式，即：

以「贫血模型」为基础的「事务脚本」的开发方式
以「充血模型」为基础的「领域驱动」的开发方式

贫血模型是指对象只用于在各层之间传输数据使用，只有数据字段和Get/Set方法，没有逻辑在对象中。而「事务脚本」可以理解为业务是由一条条增删改查的SQL组织而成，是面向过程的编程。

充血模型是面向对象设计的本质，一个对象是拥有状态和行为的。将大多数业务逻辑和持久化放在领域对象中，业务逻辑只是完成对业务逻辑的封装、事务、权限、校验等的处理。

OOA OOD OOP

Object-Oriented Analysis（面向对象分析方法）是确定需求或者业务的角度，按照面向对象的思想来分析业务。例如：OOA只是对需求中描述的问题，进行模块化的处理，描述问题的本质，区别每个问题的不同点相同点，确定问题中的对象。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。

SA SD

结构化分析（Structured Analysis，简称SA）是软件工程中的一种方法，结构化分析和结构化设计可以分析商业的需求，再转换为规格文件，最后再产生电脑软件、硬件配置及相关的手册及程序。