您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
架构之业务架构
 
作者:hp15
  114  次浏览      1 次
 2022-6-21
 
编辑推荐:
本文介绍了业务架构之产品经理的职责、业务架构之业务模块构建、业务架构之常见业务架构及业务架构之基础服务的设计。希望能够帮助大家。
本文来自于CSDN ,由火龙果软件Linda编辑、推荐。

业务架构之产品经理的职责

产品经理的职责

用户的原始需求往往是零散和碎片化的,产品经理的职责就是:告诉用户,系统长什么样子;告诉开发,他要实现什么功能。

产品经理定义了系统的外表。产品经理的职责:

1、收集用户的原始需求,

2、梳理成一个个业务流程,每个业务流程由多个业务步骤组成。一个业务步骤包含三部分的内容:输入、输出和业务功能。

3、需求梳理好后,产品经理会把每个步骤具体化为页面原型。在原型中,会以直观的方式给出各个步骤的输入或输出,以及用户的操作过程,最后再把这些页面串起来,形成一个业务流程。

业务流程例子:

按照业务域来划分系统模块,有多少业务领域,就有多个系统模块,流程中的业务节点按照业务域的不同,可以划分到不同的系统模块。

注意不是按照业务流程划分,有多少业务流程,就有多少个系统模块,这个对应关系比较直接,但实现起来很困难。而且这种模块划分的方式并没有降低总的业务复杂度。

业务划分的目标

1、业务的可扩展

业务架构设计要能支持打造一个柔性系统,通过提供良好的业务扩展性,允许业务不断调整和快速生长。

业务的主题是变化和创新,系统的主题是稳定和可靠。

2、业务的可复用

首先,模块的职责定位要非常清晰。对于模块来说,在定位范围内的职责要全部涵盖到,而不在这个范围的职责全部不要。

其次,模块的数据模型和接口设计要保证通用。架构师需要归纳业务场景,通过抽象提炼,形成通用化的设计,以此来满足多个类似场景的需求。

小提示:清晰的模块定位和通用化设计,是模块能够复用的内在要求。

最后,实现模块的高复用,还需要做好业务的层次划分。我们知道,越是底层的业务,它就相对更固定。

模块划分是需要考虑的重要问题:业务复用性。复用其实也是业务扩展性的基础。

复用的分类复用有多种形式,它可以分为技术复用和业务复用两大类。技术复用包括代码复用和技术组件复用;业务复用包括业务实体复用、业务流程复用和产品复用。从复用的程度来看,从高到低,我们可以依次划分为产品复用 > 业务流程复用 > 业务实体复用 > 组件复用 > 代码复用。

代码级复用和技术组件复用都属于工具层面,它们的好处是在很多地方都可以用,但和业务场景隔得有点远,不直接对应业务功能,因此复用的价值相对比较低。

业务实体复用针对细分的业务领域,比如订单、商品、用户等领域。它对各个业务领域的数据和业务规则进行封装,将它变成上层应用系统可以直接使用的业务组件。

业务流程的复用针对的是业务场景,它可以把多个业务实体串起来,完成一个端到端的任务。相比单个的业务实体复用,业务流程的复用程度更高,业务价值也更大。

最高层次的复用是对整个系统的复用,比如说一个 SaaS 系统(Software-as-a-Service),它在内部做了各种通用化设计,允许我们通过各种参数配置,得到我们想要的功能;或者说一个 PaaS(Platform-as-a-Service)平台,它会提供可编程的插件化支持,允许我们“嵌入”外部代码,实现想要的功能。

从技术复用到业务复用,越往上,复用程度越高,复用产生的价值也越大,但实现起来也越复杂,它能复用的场景就越有限。

但如果我们能进一步打造业务中间件,并在这个基础上,形成业务平台,这样,我们就能实现更高的业务级复用,可以更高效地支持系统的快速落地。

业务架构之业务模块构建

业务模块构建要求

每个模块都代表了某个业务概念,或者说业务领域。

模块内部由数据和业务逻辑组成,其中数据是核心,业务逻辑围绕着数据,对数据做进一步加工,方便外部使用。

对模块的要求:

1、定位明确,概念完整。数据上,模块需要覆盖对应业务领域的全部数据;功能上,模块要包含业务领域的全部功能。

2、自成体系,粒度适中。粒度划分得太小,导致系统的碎片化;体量过大的模块,我们称之为“肿瘤”,可维护性很差。

3、依赖关系明确。简化模块的依赖关系,我们就要同时简化依赖的方向和减少依赖的数量。避免松散的网状结构,尽量把网状结构转化为层次结构。

业务模块的构建步骤

构建步骤:

通过构建合理的模块体系,有效地控制系统复杂度,最小化业务变化引起的系统调整。

打造可扩展的模块体系:

1、模块拆分我们先对系统进行模块化拆分,拆分有两种方式:水平拆分和垂直拆分。

水平拆分是指从上到下把系统分为多层,按照系统处理的先后顺序,把业务拆分为几个步骤。垂直拆分指的是按照不同的业务线拆分。

一般做业务架构时,我们先考虑垂直拆分,从大方向上,把不同业务给区分清楚,然后再针对具体业务,按照业务处理流程进行水平拆分。

举例:

 

2、打造可扩展的模块体系:模块整合

通用化整合:通用化指的是通过抽象设计,让一个模块具备通用的能力,能够替代多个类似功能的模块。

平台化整合:平台化是把定位相同的模块组织在一起,以组团的方式对外提供服务。对于外部系统来说,我们可以把这些模块看成是一个整体,一起对业务场景提供全面的支撑。

业务架构之常见业务架构

服务端常见业务架构

1、单体架构

单体应用内部一般采用分层结构,从上到下,一般分为表示层、业务层、数据访问层、DB 层。表示层负责用户体验,业务层负责业务逻辑,数据访问层负责 DB 的数据存取。

2、分布式架构

分布式架构,简单来说就是系统由多个独立的应用组成,它们互相协作,成为一个整体。

3、传统SOA 架构

4、新的 SOA 架构

5、微服务架构

终端常见业务架构

分布式的系统架构App 前端直接对接多个后端应用提供的 HTTP 接口。

每个业务线的服务端进行拆分,让 App 接口和 PC 端接口各自在物理上独立,但它们共享核心的业务逻辑。

App 前端会通过移动网关来访问服务端接口。这里的网关主要就是负责处理通用的系统级功能,包括通信协议适配、安全、监控、日志等等;网关处理完之后,会通过接口路由模块,转发请求到内部的各个业务服务,比如搜索服务、详情页服务、购物车服务等等。

业务架构之基础服务的设计

基础服务边界划分的原则

1、服务的完整性原则

有些服务只是存储基础数据,然后提供简单的增删改查功能,这样一来服务只是一个简单的 DAO,变成了数据访问通道。这样的服务,它的价值就很有限,也容易被服务调用方质疑。划分服务边界时,要保证服务数据完整、功能全面,这样才能支撑一个完整的业务领域。

2、服务的一致性原则

服务内部的业务逻辑要尽量依赖内部数据,而不是接口输入的数据,否则会造成数据和业务规则的脱节(一个在外面,一个在里面),如果服务对外部的依赖性很强,就无法提供稳定的能力了。

3、正交原则

服务之间有数据的依赖关系,但没有接口的调用关系。

针对具体的业务场景,我们可以在上层的聚合服务里,通过聚合订单服务和商品服务来实现。

基础服务设计步骤

先弄清做什么:

服务边界划分,不主动调用其他服务、不负责和第三方系统的集成、只负责存储,不负责数据的进一步解释。

怎么做:

1、部分字段可配置:如流程状态等、也可配置主状态和子状态。基本状态称之为“主状态”,数量是比较有限的,状态之间的变化关系也是比较明确的,可以固定处理。子状态有哪些具体的取值,不同的项目是不一样的,可以开放给各个应用来定义。

2、拆分查询等级:查询接口可以根据返回字段数量的不同,提供三个不同粒度的查询接口来满足多样化的需求。第一个是粗粒度接口,只返回订单最基本的 7-8 个字段;第二个是中粒度接口,返回订单比较常用的十几个字段;第三个是细粒度接口,返回订单的详细信息。

3、设置不同等级的异步的消息通知。按照消息详细程度的不同,订单消息可以分为“胖消息”和“瘦消息”。顾名思义,胖消息包含了尽可能多的字段,但传输效率低;瘦消息只包含最基本的字段,传输效率高。如果外部系统需要更多的信息,它们可以通过进一步调用订单服务的接口来获取。

 

 

   
114 次浏览       1
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践

最新活动计划
需求分析师能力培养 7-10 [北京]
基于 UML 和EA进行分析设计 7-22 [北京]
知识图谱建模与应用 7-19 [北京]
用户体验、易用性测试与评估 8-18 [北京]
软件开发过程中的项目管理 8-25 [北京]
微服务开发原理与实战 8-25 [北京]
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...