• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

Recommended Posts

体系结构(ISO/IEC/IEEE-42010:2011标准):体系结构是系统在其环境中的基本概念或属性,体现在其元素、关系以及系统设计和演化的原则中。

企业架构规划(EAP):通过企业架构的规划和设计,可以帮助企业构建整体数字化战略,规划数字化项目,帮助企业通过数字化手段实现预期的战略目标和经营成果,形成企业数字化顶层规划和设计,指导企业数字化转型进程。这个企业架构规划的过程也称为企业架构规划。

系统架构(系统架构)

企业架构:它始于20世纪60年代,到现在已经发展了近60年。作为IT重点学科,经过多年的发展,广泛应用于各个行业和应用场景的各种框架和方法工具,如Zachman、TOGAF、DoDAF等。这些企业架构框架已经被用作各种企业和组织的顶层IT规划和设计的重要指导方法和工具。

观点:企业架构设计是为企业本身而设计的,因为它高度抽象,并且涉及各种利益相关者和组织。基于不同的角色和职责,不同的涉众和组织对架构有不同的关注和观点。因此,通过对不同观点的抽象,可以充分反映我们在审查和设计企业架构时处于什么样的观察位置和角度,并兼顾不同利益相关者的架构设计诉求。

视图:视图描述了由一个或一组相关的视点通过组合这些视点所关注的元模型元素及其关系,并通过设计和建模而形成的截面视图。视图反映了在一种视点下对体系结构元模型元素及其关系的描述和可视化。

企业架构框架(enterprise architecture framework):

现代企业架构框架:在充分吸收经典企业架构框架的优秀思想和最佳实践的前提下,融合企业数字化发展的最新需求和新技术、新趋势,勇敢跳出TOGAF的局限,从问题出发,回归本源,重新思考和构建一个全新的轻量级企业架构框架,切实解决企业在向现代企业架构演进过程中面临的问题和挑战,成为我们关注的焦点和研究领域。通过几年的研究和实践,一套轻量级、敏捷的企业架构框架方法逐渐形成。

元模型:元模型是对架构的核心概念元素的精确定义和描述。元模型构成了建筑设计的“基本语言元素”。通过元模型及其关系的表达,可以结构化地描述和展示体系结构。框架元模型体现了框架设计者对企业架构本身的理解和抽象,是企业架构框架的核心,是架构描述的“统一语言”。

业务架构:业务架构是企业架构的核心内容,直接决定了实现企业战略的能力,是其他架构领域的前提条件,是架构设计的主要依据。它定义了各种业务的运营模式以及业务之间的关系结构。它以承接企业战略为出发点,以支持企业战略的实现为目标。通过业务能力的识别和构建,以业务服务的形式揭示业务能力,实现对业务流程的支持,最终通过组织给予保障。业务架构包括六个部分:业务、流程、组织、服务、领域和模式。

能力:为了应对业务的快速迭代、多场景和不确定性,企业需要在平台上构建可复用的“能力”,并为能力提供必要的扩展和可变机制,从而为不同的前台提供灵活的业务服务,满足不同前台的差异化和个性化需求。根据粒度的不同,能力可以细分为三个层次:基本能力、能力组件和解决方案。不同服务的差异可以通过能力“扩展点”的设计和不同“业务身份”在扩展点的“扩展实现”来区分。

商业:“商业身份”的概念最早是由阿里巴巴提出的。当业务平台同时为所有业务提供服务时,需要能够区分每个业务服务请求的业务身份元素,以便提供差异化、个性化的服务;因此,需要对企业各项业务的身份和特征进行建模和区分,其输出就是“业务身份”。业务身份在平台中是业务的代名词,是业务运营中区分具体业务的唯一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 服务承诺。 经验:经验是特定场景中对模式的实例化应用的过程记录,经验可以加快对模式的理解,学习如何结合实际场景应用模式解决问题,经验的内容由架构模式元模型中的问题、上下文、决策三个元素组成,每个元素可以通过定义对应的参考模型展开描述。
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now