本文转载自微信公众号「逸言」，作者我是张逸。转载本文请联系逸言公众号。
通过《多维度规划业务架构》，我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构，但其本质仍然属于问题空间，其目的在于真实地探索问题空间，了解我们要解决什么样的问题。我们用到“分解”的方法，并非在解决问题，而是希望通过横向分层与纵向切分让问题空间变得更小，降低业务复杂度罢了。
这种分解层次体现为：
- 业务领域是对目标系统之系统范围进行划分，划分依据为价值高低
- 业务组件是对业务领域的划分，划分依据在于业务相关性
- 业务服务是对业务组件的划分，划分依据在于领域模型的知识语境
领域驱动进行的业务分解，既是对问题空间的探索，又自然地暗合确定解决方案的思路。由于有清晰的边界存在，这一做法并未混淆问题空间与解空间，却天然地搭建了一种映射方法，使得我们能够以较小成本将业务架构映射为IT架构中的应用架构。
映射体系如下图所示：
在图右侧所示的应用架构中，我旗帜鲜明地标记了前台、中台与后台，意味着我对应用架构的划分遵循了中台战略规划的思想。
我所理解的“中台”，满足以下定义：
- 中台是企业数字化转型的能力复用战略规划体系
- 中台是演进式的能力复用战略动态规划过程
显然，中台不是产品，也不是平台，而是一种规划体系。在企业架构的应用架构中，中台仅占据了中间代表了“能力服务层”的一部分，体现为由应用组件构成的能力中心。所谓的“能力复用战略动态规划过程”，就是在企业战略愿景的指导下，以能力复用为最终目的：
- 对于产品服务层，通过识别变化频率与复用粒度，逐步将前台的产品特性沉淀为可复用的业务能力中心
- 对于基础服务层，通过识别企业IT资产，逐步从后台的工具与框架中提炼出可复用的业务能力中心
换言之，中台不是独立的，随着时间的推移，应形成前台、中台和后台(统称为“三台”)职责之间联动;中台也不是静态不变的，同样随着时间的推移，三台的边界发生动态变化。
之所以要为应用架构建立中台，是以复用为目的，提升研发的效率和质量。能力中心的构成，使得整个企业的系统架构可以打破烟囱系统天然构成的壁垒，也有利于它的快速演化，适应企业高速发展的业务需要。
中台战略体系保留了前台，主要是为了适应创新型产品的演变。前台的设计属于产品思维的范畴，因为它牵涉到快速试错的成本，没有时间和成本考虑对复用能力的沉淀，然而，对于中台已经具备的能力中心，不妨取“拿来主义”的态度，直接复用。如此既保证了快，又保证了稳。
在我认为的“三台”中，后台并非基础设施，它同样属于业务范畴。从Pace-Layer Architecture的角度讲，后台提供的业务其区别主要在于它的变化频率更低，甚至可能几乎不变;从领域驱动设计的子领域角度讲，后台提供的业务更加通用，以至于考虑购买而非自己构建的方式实现。
如果后台稳定地提供了业务支撑，其收益高于维护成本，则不必一定要将其提炼为能力中心，甚至于它就是一个或多个相对独立而封闭的IT系统，对它的改造存在诸多阻力，改造成本极高，就得允许在企业IT系统生态中继续存在这样的遗留烟囱系统。
不管是前台的产品，还是中台的能力中心，抑或后台的工具或框架，其解决方案皆由应用组件构成，它由业务组件映射而得。本质上，业务组件与应用组件都是限界上下文，但前者对应的限界上下文只考虑了业务边界，后者对应的限界上下文在此基础上继续深化，分别考虑团队角度的工作边界和技术角度的应用边界，进一步梳理限界上下文的边界，使其与应用架构相匹配。为示区分，我将其命名为“应用组件”。
应用组件与限界上下文也有不同之处。在领域驱动设计中，限界上下文确定的是逻辑边界，而在应用架构中，还需要确定它的物理边界。物理边界的确定是从质量属性角度考虑的，例如对可扩展性、可伸缩性、低延迟、高并发的响应，技术栈的限制，资源独立性的要求，可以确定该应用组件究竟应定义为服务(Service)，还是库(library)。
通常，中台能力中心的应用组件应考虑微服务化，后台工具或框架则不然，大多数时候，定义为库可能更合适。对于前台，可以考虑一个产品对应一个微服务，也可以考虑一个产品的特性对应一个微服务。这取决于前台产品的粒度。
业务架构中纯粹表达业务的业务服务，在映射到应用架构时，被定义为应用组件需要公开在外的服务接口，我将其称之为“服务契约”，目的是体现服务调用者与服务提供者之间的一种”契约“关系。
一个业务服务映射到解空间，会定义一个服务契约;反之，一个服务契约却未必对应问题空间的业务服务——因为业务服务中的一个执行步骤也可能映射为一个服务契约。应用组件之间存在协作关系，根据业务服务的定义，如果一个业务服务的某个执行步骤由另外一个应用组件提供，就需要将其定义为另一个服务契约，但它并非业务服务。例如，“提交订单”业务服务对应于订单应用组件，需要对外公开”提交订单“的服务契约;在执行提交订单的流程时，需要验证库存，该功能由库存应用组件承担。由于订单应用组件会调用它，因而需要对外公开”验证库存“的服务契约，但”验证库存“并非一个业务服务，如下图所示：
业务服务属于问题空间的范畴，服务契约属于解空间的范畴，如此才是合理的。
服务契约对应于我提出的《菱形对称架构》中的北向网关。若应用组件为服务，则对应远程服务;为库，则对应本地服务。它们都不属于领域层的内容。业务服务的需求表现为业务服务规约，它的输入成为领域分析建模的基础;服务契约需要构成菱形对称架构的角色构造型共同协作完成，利用服务驱动设计可以驱动出领域设计模型，进而对其进行建模实现。
从产品/能力中心/工具/框架到应用组件，再从应用组件到服务契约，都有领域驱动设计的对应模式或方法去实现，由此就能实现应用架构的真正落地。若按照中台战略思想规划应用架构，意味着中台的落地也有了可供参考的实现过程与方法。
当然，通常所谓的”中台“，都会建立双中台，即业务中台和数据中台。这里参考了领域驱动设计的方法，针对的是业务中台的落地，亦可以理解为是应用架构的微服务化。至于数据中台，它关注的是全域数据的生命周期管理、数据资产的梳理与建设、全域数据分析与数据智能挖掘的数据服务，其着眼点显然和业务中台有着天壤之别，需要另外的设计方法与实现手段。
