概念
- 架构（ISO/IEC/IEEE-42010:2011 标准） ：架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则。
- 企业架构规划 (enterprise architecture planning, EAP)：通过对于企业架构的规划和设计，可以帮助企业构建整体的数字化策略，规划数字化项目，通过数字化的手段帮助其实现期望的战略目标和业务结果，形成企业的数字化顶层规划与设计，指导企业的数字化转型过程。这个企业架构规划的过程也被称为企业架构规划。
- 系统架构（System Architecture）
- 企业架构（Enterprise Architecture）：始于 20 世纪60 年代，截至目前已有接近六十年的发展历程，作为一门关键的 IT 学科领域，经过多年的发展也催生了各类广泛应用于各行业和应用场景的框架与方法论工具，例如 Zachman、TOGAF、DoDAF 等，这些企业架构框架也一直作为重要的指导方法和工具，被应用于各类企业和组织的顶层 IT 规划与设计。
- 视角（viewpoint）：企业架构设计因为是在对于企业本身的进行架构设计，因其抽象程度较高，同时涉及各类不同的干系人和组织，不同的干系人和组织基于自身所处岗位角色和职责的不同，对于架构的关注点和视角也存在比较大的差异。因此，通过不同的视角（Viewpoint）的抽象，就可以充分体现我们在审视和进行企业架构设计时，处于什么样的观察位置和角度，兼顾不同干系人的架构设计诉求。
- 视图（view）：一个视图描述了一个或一组相关的视角（Viewpoint）出发，通过组合这类视角所关注的元模型（Metamodel）要素及其关系，通过设计与建模之后，形成的切面视图。一个视图（View）体现了在一类视角（Viewpoint）下对其关注的架构元模型要素及其关系的描述和可视化。
- 企业架构框架（Enterprise Architecture Framework）：
- 现代企业架构框架（Modern Enterprise Architecture Framework）：在充分吸收经典企业架构框架的优秀思想和最佳实践的前提下，融合最新的企业数字化发展的需求和新技术新趋势，勇于跳出 TOGAF 的限制，从问题出发，回归第一性，重新思考和构建一个新的轻量级企业架构框架，切实可以解决企业在向现代企业架构演进过程中面临的问题和挑战，就成为我们重点关注和研究的领域。通过几年的研究实践，也逐渐形成了一套轻量化、敏捷可落地的企业架构框架方法。
- 元模型（Metamodel）：元模型是对于架构核心概念要素的精确定义和描述，元模型构成了架构设计的“基本语言要素”，通过元模型及其关系的表达，就可以通过结构化的方式对于架构进行描述和展现，框架元模型体现了框架设计者对于企业级架构本身的理解和抽象，是企业级架构框架的核心，是对于架构描述的“统一语言”。
- 业务架构 (Business Architecture) ：业务架构是企业架构的核心内容，直接决定了企业战略的实现能力，是其他架构领域工作的前提条件和架构设计的主要依据。定义了企业各类业务的运作模式及业务之间的关系结构。它以承接企业战略为出发点，以支撑实现企业战略为目标，通过对于业务能力的识别与构建，并将业务能力以业务服务的方式透出，实现对于业务流程的支撑，并最终通过组织给予保障。业务架构整体上包括“业务”、“流程”、“组织”、“服务”、“领域”和“模式”六大部分。
- 能力：企业为了应对业务的快速迭代、多场景和不确定性，需要在平台上构建可复用的“能力”以及为能力提供必要的扩展与可变机制，以此为不同前台提供灵活多变的业务服务，满足不同前台差异化个性化的的需求。“能力”根据粒度的不同，可再度细分为“基础能力”、“能力组件”和“解决方案”三个层级。不同业务的差异性，则可通过能力的“扩展点”设计和不同“业务身份”在扩展点上的“扩展实现”进行区分。
- 业务身份：“业务身份”的概念最早由阿里巴巴提出，业务平台在对各业务同时提供服务时，需要能区分每一次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此需要对企业各业务的身份和特征进行建模和区分，其产出即为“业务身份”。业务身份是业务在平台中的代名词，是在业务运营中唯一区分某个具体业务的 ID。平台基于业务身份匹配该特定业务的流程和业务规则，并基于业务身份实现服务路由、需求溯源、业务监控和业务隔离。
- 基础能力：是对领域对象的原子操作，完成一个领域对象上单一且完整的职责。比如：创建售后单、修改商品库存量等，是能力组合和复用的最小单元。
- 能力组件： 能力组件是对基础能力的进一步封装，目的是方便业务的使用。按封装粒度不同分为两类：第一类能力组件是根据业务服务的需要编排封装的一组关联的基础能力，从而提供完整的服务。比如：订单创建能力组件。第二类能力组件是平台针对一系列紧密关联的业务活动，设计的能力模板，可基于该模板快速定制某个具体业务的特定流程和能力，从而达到复用全部关联能力的目的。比如：“组合支付”、“快速建站”等能力组件。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。
- 扩展点与扩展实现：“扩展点”是对基础能力的可变性设计，在技术侧体现为基础能力实现中的某一个步骤的接口定义，而接口的一个实现即为一个“扩展实现”。比如：订单渲染基础能力中有一个步骤是订单总价试算，而正常时期的总价试算规则与秒杀时期的总价试算规则是不同的，因此需要对订单渲染基础能力设计“订单总价试算规则”的扩展点，并分别定义在正常时期和秒杀时期的扩展实现。
- 解决方案：是平台针对一类共性业务的端到端过程设计的能力模板；可基于该模板快速定制某个具体业务的特定能力和流程，从而达到业务模式级别复用的目的。比如：虚拟物品交易解决方案。
- 流程建模： 负责识别共性业务，并抽取通用流程，设计可变点，作为可复用性分析的基础。
- 领域建模： 负责基于流程建模结果，识别领域事件和领域对象，并划分子域的边界；领域对象构成了提供可复用能力的基本单元，对领域对象的操作即是基础能力。
- 业务身份建模：负责定义业务身份识别的要素和业务身份解析规则，用于给可复用的能力区分不同的业务身份要素。业务身份由“业务身份 ID”、“业务身份名称”、“业务身份要素定义”、“业务身份识别解析规则”四个部分组成。
- 能力建模：负责最终完成平台三类可复用能力的设计，即“基础能力”设计、“能力组件”设计和“解决方案”设计。
- 领域事件（Domain Event）：是领域专家关心的，在业务上真实发生的事件，这些事件对系统会产生重要的影响，如果没有这些事件的发生，整个业务逻辑和系统实现就不能成立。我们可以通过领域事件对过去发生的事情进行溯源，因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。比如：“用户地址已更新”、“订单已发货” 等领域事件。
- 事件风暴（Event Storming）：
- 领域对象（Domain Object）：是对业务的高度抽象，作为业务和系统实现的核心联系，领域对象封装和承载了业务逻辑，是系统设计的基础。
- 聚合根：是领域对象的根节点，具有全局标识，对象其它的实体只能通过聚合根来导航；如订单可以分为订单头和订单行，订单头是聚合根，它包含了订单基本信息；订单行是实体，它包含订单的明细信息，聚合跟所代表的聚合实现了对于业务一致性的保障，是业务一致性的边界。
- 实体：是领域对象的主干，具有唯一标识和生命周期，可以通过标识判断相等性，并且是可变的，如常见的用户实体、订单实体；
- 值对象：实体的附加业务概念，用来描述实体所包含的业务信息，无唯一标识，可枚举且不可变，如收货地址、合同种类等等。
- 子域（Subdomain）：是对问题域的澄清和划分，同时也是对于资源投入优先级的重要参考。比如：“订单子域”、“物流子域”等，子域的划分仍属于业务架构关注范畴。
- 核心域（Core Domain）：是当前产品的核心差异化竞争力，是整个业务的盈利来源和基石，如果核心域不存在那么整个业务就不能运作。对于核心域，需要投入最优势的资源（包括能力高的人），和做严谨良好的设计。
- 支撑域（Supporting Subdomain）：解决的是支撑核心域运作的问题，其重要程度不如核心域，但具备强烈的个性化需求，难以在业内找到现成的解决方案，需要专门的团队定制开发。
- 通用域（Generic Subdomain）：该类问题在业内非常常见，所以很可能有现成的解决方案，通过购买或简单修改的方式就可以使用。
- 基础能力：是对领域对象的原子操作，完成一个领域上单一且完整的职责。比如：创建售后单、修改商品库存量等。
- 扩展点与扩展实现：“扩展点”是对基础能力的可变性设计，在技术侧体现为基础能力实现中的某一个步骤的接口定义，而接口的一个实现为一个“扩展实现”。比如：订单渲染基础能力中有一个步骤是订单总价试算，而正常时期的总价试算规则与秒杀时期的总价试算规则是不同的，因此需要对订单渲染基础能力设计“订单总价试算规则”的扩展点，并分别定义在正常时期和秒杀时期的扩展实现。
- 能力组件：是对基础能力的进一步封装，目的是方便业务的使用。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。
- 业务维度：此维度主要对企业的业务组合管理进行建模，分析企业各主营业务和辅助业务的关系结构及运作模式。
- 业务群：是企业基于业务战略拆解，确定开展的特定经营活动。比如：开展 ToC 的电商平台经营活动，其下又进一步细分为快消品业务群和消费电子业务群等。
- 业务：是业务群下具有业务价值的业务单元。比如：实体商品业务、生活服务业务等；内部支撑类的业务比如人力资源管理等。
- 场景：是面向用户提供价值的端到端业务场景。通常从 4W1H（What、Who、Where、When、How）的维度识别和定义业务场景要素，然后从业务场景要素的排列组合中筛选出有实际意义的业务场景。
- 流程维度：主要对企业的业务流程进行分层建模，分析企业如何通过一系列业务活动，按照相关的业务规则将输入转换成为有价值的输出，从而实现用户价值。
- 阶段：即业务流程阶段，包含一组用户的及与用户交互的业务活动，用以实现阶段性价值交付的目的。比如：售前、售中和售后等。
- 活动：即业务活动，是某个业务角色办理的业务事项，包含一个或一组任务，有明确的业务成果和业务输出。比如：商品发布、活动发布等。
- 任务：是完成活动的工作程序，是流程的基本组成单元。比如：查询商品详情、更新商品库存、创建订单等。
- 步骤：是完成任务的具体步骤，是流程的最原子操作。比如：校验用户状态、校验商户状态、订单总价试算等。
- 业务规则：是定义或约束业务某些方面的陈述，旨在维护业务结构或控制或影响业务行为，它描述业务过程与决策过程。比如：if订单.提货方式=“邮寄”且 订单 . 支付状态 =“已支付” then “创建物流单”。
- 组织维度：主要对企业的组织体系进行分析。公司组织体系指为了保障战略和业务规划落地，以及有效实施业务流程体系，公司采取的组织架构和管控模式。
- 组织单元：是公司组织体系的组成单元。
- 岗位：是随组织结构设定的，要求个体完成的一项或多项责任以及为此赋予个体的权力的总和。
- 角色：是业务流程中活动参与者的原型，参与者在流程中的位置通过担任合适的角色确定。组织为完成某一目标，往往会把此目标分解，以便能交给不同能力和责任的角色合作完成。
- 服务维度：主要对企业对内和对外提供的业务服务进行建模分析。
- 业务服务：是企业和企业的每个业务单元为其客户提供的内部和外部服务。服务是能力对外呈现价值的方式，是具备明确的业务特征，独立完整、由一个或多个关联紧密的功能组合的集合。比如：开户、提交订单等。
- 限界上下文（Boundary Context）：是业务上下文的边界，在该边界内，当我们去交流某个业务概念时，不会产生理解和认知上的歧义（二义性），限界上下文是统一语言的重要保证。
- 统一语言（Ubiquitous Language）：是 Eric Evans在《域驱动设计 - 处理软件核心中的复杂性》中使用的术语，用于构建由团队，开发人员，领域专家和其他参与者共享的语言，也称为无处不在的语言、通用语言、泛在语言。统一语言是在限界上下文中建模的，在其中标识表达了业务领域的术语和概念，并且不应该有歧义。
- 应用组：是一种大比例结构的逻辑边界划分结构
- 应用组件：是一种细粒度的应用逻辑边界划分结构，是对功能、数据的封装。按职责类型分解，流转类、规格类、视图类、配置类。
- 应用层建模：除了应用组之外，常见的一种大比例结构是分层，因此我们也将应用层作为一种元素加入进来。我们认为分层代表了企业对变化速率的认知，并为不同的变化速率匹配架构设计目标和管理方法。
- 应用服务：元模型中的应用服务最主要的作用是显式地向对外定义一个契约。这在做应用组件升级 / 替换、定义IT 服务级别等架构治理场景中会有帮助。应用服务可用来对一组相关的应用组件功能集合建模。
- 数据分析三大工序：摄取（Ingest）- 加工（Process）- 能力包装（Serve）
- 数据对象：是数据架构的核心模型，是从数据视角对现实世界特征的模拟和抽象。
- 贴源层：贴源代表紧靠数据源，某个业务场景自身的业务运营分析需求，其需要的绝大部分数据原料就在支撑这个业务场景的应用中，需求和实现相对稳定。例如，销售线索响应的前置时间趋势，其依赖的主要数据原料是销售线索的跟进事件，它们就在销售线索管理系统这个数据源里。
- 衍生层：在贴源层之上的是衍生层，这里的分析类场景需要整合多个数据源的数据原料，往往需要经过多次中间处理，实现难度较高，并且需求和实现相对容易变化。例如，整合多个数据源的客户行为数据，为客户打上标签。
- 架构模式元模型：模式分析是快速认识问题本质以及经验复用的有效实践，我们在元模型内容中增加了架构模式模型，引入模式分析视角，对上层架构设计意图、问题进行分析建模，目的是快速、准确定位设计和复用技术方案。
- 架构方案元模型：架构方案模型是描述技术架构设计的核心元模型，包含三个主要核心元素。基于平台型企业架构技术设计的特征，我们使用了平台、服务、组件这三个层次递进的元素对技术架构进行建模。
- 架构策略元模型：架构策略模型是为了约束和规范架构设计过程，保证架构设计遵循企业整体的架构设计愿景与需求，符合企业整体的架构设计原则与规范，是对于架构设计过程本身的约束和指导。
- 问题 Problem：问题和上下文是对上层架构设计输入的分析和解读。问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺（SLA）。
- 上下文 Context：问题和上下文是对上层架构设计输入的分析和解读。上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等。
- 模式 Pattern：模式是通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践。模式是解决某一类问题的方案原理的总结，通过模式技术人员可以快速构成对问题及方案背后原理的理解，在问题不变时，模式具有相对的稳定性，是沉淀技术知识的最佳形式。
- 决策 Decision：决策描述了在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策树或决策表。
- 技术组件 Component：技术组件用于描述技术服务的实现，是可部署的物理组件，例如可运行的软件系统或构建打包后的应用组件，技术组件通过架构模式的决策元素，与技术选型进行关联。
- 技术服务 Service：技术服务用于描述实现上层架构设计意图所需的技术能力（或功能），例如网关、防火墙、数据存储、缓存等。技术服务属于逻辑模型，作为一种对服务能力的描述，与之相关的 SLA 等跨功能性需求会同时作为其参考描述信息。
- 技术平台 Platform：技术平台是用于描述由一组技术服务构成，提供解决特定技术领域能力的逻辑模型，它主要用于从更高的层次对技术服务进行管理，简化架构参与者对复杂架构的理解和使用，统一对用户提供一致的SLA 服务承诺。
- 经验：经验是特定场景中对模式的实例化应用的过程记录，经验可以加快对模式的理解，学习如何结合实际场景应用模式解决问题，经验的内容由架构模式元模型中的问题、上下文、决策三个元素组成，每个元素可以通过定义对应的参考模型展开描述。