- 抽象的A、B、C这样的描述是没有代入感的。遇到实际的业务逻辑，仍然不知道怎么拆解。
- 在实际的业务实现过程中，经常发现 Autonomy 的反模式。这些反面例子比正面例子更有教育意义。
- 书本上理想化的说教经常没法套入产品经理乱七八糟的需求里。我不仅仅需要看上去美的小例子，也要有一些实现起来其实挺难受的恶心例子。
产品经理很少会从 Autonomy 的角度去思考问题，更多是从整体效果的角度来看。 拆分是因为"没法把实现都写一起"，这个现实约束引起的副作用，是产品经理无法感知的实现细节。 产品经理和开发者的常见矛盾就在于一方从整体效果出发，而另外一方则从拆分出的细节出发。 熟知需求模式，是为了把纷繁复杂的需求，往有限的模式里套。 当套不进去的时候，思考一下这个地方做得这么特殊有什么特别的收益吗？
开发者经常陷入的一个误区是从名词出发。比如在应用 Domain Driven Design 的时候，会去想什么叫“商品”呢？ 一个名词什么都不是，又可以什么都是。 纠结一个词是什么意思，毫无意义。 我们的目标是实现业务逻辑，把业务逻辑做好拆分。这些业务逻辑的外在表现才真正定义了什么叫“商品”，什么叫“线索”，什么叫“工单”。 常见的外在表现不外乎 UI 长什么，流程是什么。所以我们来具体看看常见的 UI 和流程需求怎么能从 Autonomy 的角度拆好：
中国企业喜欢包办一个客户的所有需求，这和国外崇尚专业化的做法是非常不同的。这就导致了中国式的 App 从需求上就包括
- 所有的功能都要挤到同一个App的同一个界面的同一个流程里去实现。特别是要往主业务里挤，这样才能分到流量。
- 业务与业务之间有网状的互联互通需求。比如 Uber 就不会分专车，快车，优享。但是国内的业务就会分得很细，彼此之间又要倒流升舱一键呼叫。
中台的出现，不是为了复用，减少新业务的软件开发成本。软件开发能有多少成本，或者说能省多少成本。 不是因为我们认为需求都差不多，可以归纳出可复用的预制件，然后沉淀到中台去。 中台的本质是为了让上面这样的深度整合的需求因为集中到一个部门能做得更快一些。这种类型的需求也许是有中国特色的。 与传统企业财务集中那样的离线整合不同，这里的集成需求需要是在线，深入参与客户交互体验过程之中的。 如果让主界面被任意一个业务所全部独占，其他业务与其合作就阻力会更大一些。 “收口”到中台可以方便业务之间实现稀缺资源的共享（分配，撕逼），也方便业务之间的互联互通，减少适配成本。
中台的本质是“中间的台”，是因为其位置在中间，把各种业务各种功能整合集成到了一起。 过去某种特定的实现中台的技术方案可能会过时，会消失。 但是只要中国式的 App 风格不变化，对中台的需求是不会消失的。
最大化客户 LTV 在获客成本高企的今天有其合理性。 技术是为业务成功服务的。如果业务需要高复杂度的逻辑整合，那么技术写得出来得写，写不出来也得写。
希望前面提过的几种业务逻辑拆分模式可以让我们对于中台该做什么，不该做什么，有一个不同的视角的认识。 以这个虚构故事自省：
中台部门自称自己是 Software Product Line，提供了一堆预制件以及装配用的 DSL，能加速新业务的快速上线与试错。
CTO 希望中台是 Central Platform 削平内部的山头，打通数据和权限的利器。
实际不小心落地成了 Middle Office（Middle 衙门），只要从此过，留下买路财的官僚机构。
当我们拆分出了一堆Git仓库之后， 对于某些集成的需求（并不是所有的集成需求都是如此）使用星型的集成比点对点的集成更经济。 这个负责集成的Git仓库需不需要一个专职的团队，是不是一定要是独立的进程，是不是要创建一个名为中台的组织？ 与财务，法务，市场，营销，人力资源等职能不同，这些职能是有自己的专职工作内容的，对技能的要求是有专业性的。 有 HRBP，那需要中台 BP 吗？ 业务逻辑拆分模式只探讨到Git仓库的拆分，关于Git仓库如何与组织架构对应起来，留给读者自行寻找答案。