@
okey 这问题以前我也思考过，下层的一些服务后期可能会演进孵化成为一个具有独立功能、具备支撑能力、可灵活接入的应用，不仅仅需要提供给维护中台的人操作页面，也可能需要中台为上层服务团队的人提供操作页面，例如这种形式：业务层应用需要接入使用中台层服务，那么直接通过中台提供的页面创建应用，然后得到 appid 、appsecret ，通过中台提供的相关接入方式做集成开发，就使得上层应用接入到了下层中台中，并使用中台提供的功能服务。
但是有个问题我也是长久以来的思考，就是，当中台发展到一定程度，例如我上述所说发展到类似一个完整独立的应用。此时，中台与上层业务层的关系会发生什么微秒的变化？目前架构中对我来说比较烦的两个问题，一个是拆分的粒度粗细把握，另一个是拆分后各种模块之间应该是怎样的关系。
我之前看领域驱动设计时，其中提到了限界上下文之间的协作关系（通俗的讲就是各个服务之间的协作关系），有如下几种：
- 合作关系（ Partnership ）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（ Shared Kernel ）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（ Customer-Supplier Development ）：上下文之间有组织的上下游依赖。
- 遵奉者（ Conformist ）：下游上下文只能盲目依赖上游上下文。
- 防腐层（ Anticorruption Layer ）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（ Open Host Service ）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（ Published Language ）：通常与 OHS 一起使用，用于定义开放主机的协议。
- 大泥球（ Big Ball of Mud ）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（ SeparateWay ）：两个完全没有任何联系的上下文。
当拆分成各种服务时，势必可能对应到组织架构的拆分（康威定律），例如你所说会有两拨人分别维护。所以这两拨人之间如何合作，就意味着服务之间的处于怎样的关系，同时也是 5 楼 @
9136347 中提到可能会有谁听谁的问题，这都与组织架构有关系。
所以服务之间的关系建议看一下领域驱动中的这几种限界上下文映射关系，并且哪种关系适用于哪种场景。
但是比较重要的一点是，无论怎么拆，我个人觉得最好能够画出架构的逻辑图出来，从架构图上我们可以看清哪部分属于整体架构的哪部分，讲拆分我们都是讲的逻辑的拆分，并不一定代表着物理上的拆分，主要就是让逻辑结构清晰，物理上要拆分的话，就是要考虑工作量、技术上的具体实施问题了。所以你说“这种拆法数量比较难受”可能指的是物理上要拆这么多是吧？
最后再回到你的问题上，中台需要提供操作和页面，那么分层肯定还是要的。假设中台一开始建立的时候，与上层业务的关系是合作关系，大家都遵循同样的需求一起开发，此时中台页面可能是放在当前架构下的业务层。但发展到后期，中台可能发展成为一个独立的应用，中台团队也具有比较大的独立性，那么中台与原来业务层的协作关系可能就发生了改变，深入到中台的架构视图中，中台自己拥有独立的纵向和横向划分体系，此时的中台的操作页面可能就纳入到这个体系的应用层中了，而不是在原来体系的应用层中。
----
以上纯属我个人的理解和看法，另外我暂时还没有从真正实施过这样大规模的工程，目前只是纯理论阶段，如果有架构大神在话的，希望能提供一些指导意见