业务架构设计方法

来源:架构师修炼之道

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

1、产品经理的职责

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

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

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

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

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

业务流程例子:

bf69364a02a52df1ca48d559a783092a.jpeg

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

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

771b3279c74f536322208e44758227ef.png

2、业务划分的目标

1)业务的可扩展

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

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

9ecdb797940e02df635d4238e71469b7.png

2)业务的可复用

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

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

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

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

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

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

d05f9c9fb60c5612b71df745a4cb567e.png

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

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

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

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

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

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

02 业务架构之业务模块构建

1、业务模块构建要求

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

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

对模块的要求:

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

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

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

2、业务模块的构建步骤

构建步骤:

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

打造可扩展的模块体系:

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

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

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

举例:

c22da964f7b708835e9f1fdacee0e0ee.jpeg

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

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

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

03 业务架构之常见业务架构

1、服务端常见业务架构

1)单体架构

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

39990fe50e6be3467f09bc49bc6b9f47.png

2)分布式架构

c3aebb59c427568b77d3fe3a4edc288c.png

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

3)传统SOA 架构

032fc3ae8a3969f26bad2ed1e0beb372.png

4)新的 SOA 架构

813d7e85bee49b263b93e35fb542fb07.png

5)微服务架构

c4272587c950da8300ed4e5644311994.png

2、终端常见业务架构

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

cf51b723950a90e4bd679be2006edbca.png

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

990cecbefd4c0a8eb329fef2d8cd2b38.png

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

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

1、基础服务边界划分的原则

1)服务的完整性原则

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

2)服务的一致性原则

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

3)正交原则

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

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

2、基础服务设计步骤

先弄清做什么:

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

怎么做:

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

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

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

推荐阅读:
被 GPT-4 Plus 账号价格劝退了!
世界的真实格局分析,地球人类社会底层运行原理
不是你需要中台,而是一名合格的架构师(附各大厂中台建设PPT)

企业IT技术架构规划方案

论数字化转型——转什么,如何转?

华为干部与人才发展手册(附PPT)
【中台实践】华为大数据中台架构分享.pdf

华为的数字化转型方法论

华为如何实施数字化转型(附PPT)
华为大数据解决方案(PPT)
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值