业务能力是服务化变革的入手点。企业级的变革项目一般是面向企业愿景，驱动业务变革，引导和落实业务模式、组织架构和运营模式的变革。这些变革点首先体现在业务能力的变化中，进而落实到人才、流程和技术工具的变更
业务场景是业务流程的分类。不同业务人员对业务能力进行分解的维度（也称为场景因子）可能不相同，但只要符合 MECE 分析法（Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”），并根据关键场景因子覆盖了全部关键业务活动，对最终设计应用服务的影响不大。
工作流/业务活动及其下层的任务。业务活动是业务人员描述和设计业务的最小单元，包括业务角色、输入输出交付件和业务规则。业务活动的颗粒度非常重要，不同部门编制和发布的业务活动的颗粒度可能差别很大
业务服务(业务组件)是将一组可重用的业务活动及串接逻辑封装起来，面向不同场景提供一个完整的业务功能。一个业务能力可以提供一个或多个业务组件。业务组件对外提供标准化接口，通过灵活编排，快速实现复杂多变的业务场景。业务组件内部的优化不影响对外的接口，有利于业务的敏捷和创新
业务对象是可以独立存在的数据实体，可以分解为逻辑数据实体，进而再分解为属性字段。业务对象相当于“领域驱动设计”方法（DDD）中的聚合根（Aggregate Root），是一个业务领域的数据实体代表。业务对象也是数据治理的最小单元。围绕着业务对象可以设置数据 责任人，制定数据治理流程和指标。
是应用服务的核心，也是将围绕业务对象的业务活动归拢到应用服务的依据
应用服务相当于“领域驱动设计”方法（DDD）中定义的一个有界上下文（Bounded Context）
既是业务要素，又是应用要素，封装了业务对象和围绕业务对象的业务活动，并以 API 的方式暴露系统功能。应用服务是业务、信息和功能的聚合，实现业务、数据与系统功能的拉通。如果对应用服务独立部署，则应用服务是业务架构、信息架构、应用架构和技术架构的结合体。应用服务不应由业务人员或 IT 人员单独设计，应组织业务代表、系统分析师 BA、信息架构师 IA 和系统架构师 SE 等角色共同设计。
应用系统模块是产品部署的物理单元。一个或几个关联紧密的应用服务组合为一个应用系统模块。应用系统模块的颗粒度不宜过小，否则可能出现应用服务间过于频繁的信息交互，导致服务运营困难。
