本文转载自微信公众号《一言》，作者张译。转载本文请联系一言公众号。通过《多维度规划业务架构》，我们得到了一个由三个层次组成的业务架构：业务领域-业务组件-业务服务。虽然是架构，但本质还是属于问题空间。它的目的是真正探索问题空间，了解我们要解决什么样的问题。我们采用“分解”的方法，不是为了解决问题，而是通过横向分层，纵向切分，把问题空间变小，降低业务复杂度。这一层次的分解体现在：业务域是目标系统的系统范围的划分，划分依据是高低价值业务组件是业务域的划分，划分依据是业务关联业务服务是对业务组件的划分，划分是基于领域模型的知识上下文领域驱动的业务分解，既是对问题空间的探索，也自然不谋而合的思路确定解决方案。由于存在清晰的边界，这种做法并没有混淆问题空间和解决方案空间，而是自然而然地构建了一种映射方法，使我们能够以相对较低的成本将业务架构映射到IT架构中的应用架构。映射系统如下图所示：在图右侧所示的应用架构中，我已经明确标出了前台、中台、后台，也就是说我对应用架构的划分遵循了这样的思路中台战略规划。我理解的“中台”满足如下定义：中台是企业数字化转型中能力复用的战略规划体系中台是演化能力复用策略的动态规划过程显然，中台既不是一个产品，也不是一个平台，而是一个规划系统。在企业架构的应用架构中，中台只占据中间代表“能力服务层”的部分，体现在由应用组件组成的能力中心。所谓“能力复用策略动态规划流程”，就是在企业战略愿景的指导下，能力复用的最终目标：对于产品服务层，通过确定变更频率和复用粒度，逐步沉淀前端的产品特性作为可复用的业务能力中心，对于基础服务层，通过识别企业IT资产，从后台工具和框架中逐步提炼出可复用的业务能力中心。也就是说，中台不是独立的，随着时间的推移，前台、中台、后台（统称“三办”）的职责之间应该会有联动；中台不是一成不变的，三台的边界会随着时间的推移而动态变化。之所以为应用架构建立中台，是为了提高研发效率和质量，以达到复用的目的。能力中心的组成使得整个企业的系统架构能够突破烟囱系统的天然壁垒，也有利于其快速演进以满足企业快速发展的业务需求。中台战略体系保留前台，主要是为了适应创新产品的演进。前台的设计属于产品思维的范畴，因为涉及到快速试错的成本，没有时间和成本去考虑可重用性的沉淀。但是，对于中台已有的能力中心，可能是“用”的态度，直接复用。这确保了速度和稳定性。“三平台”中我觉得，后台不是基础设施，也属于业务范畴。从Pace-LayerArchitecture的角度来看，后台提供的服务的区别在于变化的频率较低，甚至可能几乎不变；从领域驱动设计子领域来看，后台提供的服务更通用，可以自己购买，而不是自己构建。如果后台稳定提供业务支持，收益高于维护成本，则不必细化为能力中心，甚至一个或多个相对独立封闭的IT系统，其转型阻力重重，改造成本极高，因此有必要让这样的遗留烟囱系统在企业IT系统生态中继续存在。无论是前端产品、中端能力中心，还是后端工具或框架，解决方案都是由应用组件组成的，应用组件是由业务组件映射而来。本质上，业务组件和应用组件都是限界上下文，只是前者对应的限界上下文只考虑业务边界，而后者对应的限界上下文在此基础上不断加深，从工作的角度考虑工作边界从技术角度看团队和应用。Boundary，进一步梳理限界上下文的边界，以匹配应用架构。为了区别起见，我将其命名为“ApplicationComponent”。应用程序组件和限界上下文之间也存在差异。在领域驱动设计中，限界上下文决定了逻辑边界，而在应用架构中，还需要确定其物理边界。物理边界的确定是从质量属性的角度考虑的，比如对可扩展性、可扩展性、低延迟、高并发的响应、技术栈的限制、资源独立性的要求等。可以确定应用程序组件应该定义为服务（Service），还是库（library）。一般来说，中台能力中心的应用组件应该考虑微服务，后端的工具或框架则不需要考虑微服务。大多数时候，将它们定义为库可能更合适。对于前台，可以考虑一个产品对应一个微服务，也可以考虑一个产品特性对应一个微服务。这取决于前台产品的粒度。业务架构中纯粹表达业务的业务服务定义为应用组件映射到应用架构时需要暴露的服务接口。我称之为“服务契约”来反映服务调用者和服务提供者。之间的一种“契约”关系。当业务服务映射到解决方案空间时定义服务契约；相反，服务契约不一定对应于问题空间中的业务服务——因为业务服务中的执行步骤也可能映射到服务契约。应用程序组件之间存在协作关系。根据业务服务的定义，如果业务服务的某个执行步骤是由另一个应用程序组件提供的，则需要定义为另一个服务契约，但它不是业务服务。例如“提交订单”业务服务对应订单应用组件，需要公开“提交订单”服务契约；在执行提交订单的过程中，需要对库存进行校验，该功能由库存应用组件承担。由于订单应用组件会调用它，所以需要对外公开“VerifyInventory”的服务契约，但是“VerifyInventory”不是业务服务，如下图：业务服务属于类别的问题空间，而服务契约属于解空间的范畴，因此是合理的。服务合约对应我提议的《菱形对称架构》中的北向网关。如果应用组件是服务，则对应远程服务；如果是图书馆，则对应本地服务。它们都不是域层的一部分。业务服务的需求由业务服务规范表示，其输入成为领域分析和建模的基础；服务契约需要通过形成菱形对称结构的角色定型的合作来完成。服务驱动设计可以用来驱动领域设计模型，然后对其进行建模。从产品/能力中心/工具/框架到应用组件，从应用组件到服务契约，都有相应的领域驱动设计模式或方法来实现，从而实现真正的应用架构。如果应用架构是按照中台的战略思想来规划的，那么意味着中台的实施也有参考的实施流程和方法。当然，所谓“中台??”通常是建立双中台，即业务中台和数据中台。这里我们指的是领域驱动设计的方法，它针对的是业务平台的实现，也可以理解为应用架构的微服务。数据中台侧重于全域数据的生命周期管理、数据资产的梳理和构建、全域数据分析和数据智能挖掘的数据服务。设计方法和实现手段。
