如何进行系统分析与设计

xiaoxiao2021-03-01  10

概述

首先,系统是什么?根据《系统架构》一书的定义,系统是由一组实体和这些实体之间的关系所构成的集合,其功能要大于这些实体各自的功能之和。对于我们的场景,系统可能是 App、Web 应用、服务、批处理程序等,也可能是包括所有这些的一个大系统。

随着互联网和传统企业的结合越来越深入,业务会越来越复杂。我们该如何设计我们的系统呢?

从产品到研发

从产品作出原型,到研发编程实现,中间有巨大的鸿沟。越复杂的业务需求,这条鸿沟就越大。一般而言,我们至少还要有两个步骤:业务分析与架构设计。

业务分析,主要处理的是业务领域的建模。解决的问题是业务上如何实现。然后是技术与架构方面的设计,主要针对的是技术实现,解决的问题是技术上如何实现。这两个方面是会互相影响的,设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构,当然相应的也需要更新文档。

基本原则

设计与分析的过程就是不停的进行抽象和封装,并且确定各个系统实体的细节。抽象是指将业务抽象为软件领域的元素(系统、模块或类);封装则是指定义元素的边界,隐藏实现,开放接口。

相应的,分析与设计时,最基本的原则就是抽象性和封装性。当然,我们有 SOLID、DRY、高内聚低耦合、设计模式等各种原则和方法,具体方式本文不详述了,但最终它们都可以归类到以上两点。

业务分析

分析方法

业务分析是针对业务领域的建模,产出就是分析模型。分析模型描述系统的逻辑设计与结构,一般会包括需求用例、实体模型以及业务场景的交互流程、状态转换等。分析模型让非技术人员能够理解系统是如何构造的,让技术人员能够以此为基础搭建系统。

分析的过程是不断迭代的。特别对于复杂的、涉及多个业务领域的需求,第一步往往需要在整体系统的层级进行分析,然后将模型划分到多个子系统,然后再在子系统的层级进行更细节的分析与建模。

另一方面,分析过程中需要不断的优化和调整。例如在确定实体的行为细节时,发现两个实体的耦合很高,那么可能需要重新进行抽象,调整实体的功能范围。

理清业务需求

理清业务需求是所有分析与设计的前提:

确定系统的利益相关者(Stakeholder)及他们的关注点。

确定系统的业务需求,即「谁」使用该系统「做什么」。

确定系统的功能范围,即该系统「包含什么」,不包含「什么」。

系统需要满足利益相关者的关注点,所以要确保所有这些关注点都有涉及到。最重要的利益相关者当然就是用户(有时还会细分为不同类型的用户),此外还应该包括供应商、合作方、运营、销售、老板甚至政府等等,也同样包括研发测试和运维。

具体到系统的用户,还需要细分到角色,即使有些角色实际可能是同一个人。比如对于门诊,可能有护士、顾问或系统管理员等等,可以进行不同的操作。需求范围简单话用一个列表即可,复杂的系统可以考虑使用用例图。

例如,门诊预约系统的用例图可以这样画:

角色有医生、患者和门诊员工。

用例有设置排班、管理预约以及预约/取消医生。

建立实体模型

实体模型是确定系统包含的实体以及它们之间的关联的过程:

理清业务概念,统一业务词汇。

抽象业务实体,包括事件、人/角色、地点和事物等。

识别实体关系:继承、聚合、关联等。

实体模型也叫 ER(Entity-Relation)模型。可以考虑使用四色法建模,一般可以使用类图或组件图表示。需要注意的是一定要理清业务的概念,统一命名和定义业务相关词汇,这是进一步沟通的基础。

例如,预约系统的实体关系图可以这样画:

分析业务场景

场景分析用于确定具体业务场景中,各个参与者的交互过程,从而进一步完善分析模型:

分析具体业务场景,确定业务规则,梳理业务流程。

如果涉及复杂的状态转换,需要确定状态转换逻辑。

补充和完善实体模型的内容描述。

对于一个业务场景,参与者可能包括人、内部模块、外部服务等,这一步需要理清楚整个业务过程和规则。需要注意的是,对于一些次要路径或者异常路径,也一定要考虑到。对于业务过程和规则,可以使用普通的流程图、泳道图,也可以考虑UML的活动图,状态转换过程则可以通过UML的状态图展示。

对于场景分析中不太确定的需求,或者可能会有技术难点地方,可以记录下来,后面确认和验证。

例如,下面是预约系统的预约状态图。

例如,下面是我们和一家药品供应商对接的流程图。

架构与技术设计

架构方法

架构设计不一定要深入到具体的实现细节,但是应该尽量全面的考虑系统的各个方面。关键是要对项目风险有比较大的把握,这样才能避免开发过程出现不可控的问题。具体设计需要多详细,是需要设计者自己去把握度的。

对于暂时无法确定的内容,应该在文档中注明,在开发过程早期进行试验和验证。如果对项目比较关键,可以考虑先行开发原型来进行验证。

架构设计常见的是4+1视图,即逻辑视图、开发视图、过程视图、物理视图,再加上场景。另外一种我更喜欢的是视点和视角的方法,如果再加上场景的话,可能会更全面。

确定整体架构

首先需要在整体上考虑系统的位置和职责:

确定系统在整个上下文中的位置,与其他系统的关联。

确定系统自身以及各个外部系统的职责。

整体架构对应的就是情景视图。这一步将系统看作一个黑盒,确认系统自己的范围和职责,相关的外部系统的职责,以及他们之间的关联。

例如,交易系统的整体架构大概是这样的:

设计功能模块

其次需要确定系统内部的功能模块及其职责:

确定系统的模块划分。

确定每个模块的职责以及模块间的关联。

功能模块对应的就是功能视图。这一步需要明确系统的内部结构。内部模块划分主要有基于业务功能的划分,以及基于实现层次的划分,稍复杂的系统可能会两者都有。也有一些系统会采用CQRS等架构,那么模块划分可能会不一样。功能模块可以使用UML的组件图表示。

明确架构关注点

然后需要确定系统架构的理念:

理清架构设计需要考虑的关注点。

确定系统的架构设计上的取舍。

这一步需要考虑各种架构视角,主要有(但不限于)以下关注点:

安全性:身份验证、权限控制和授权、操作日志、安全审计、数据一致性等。

性能:响应时间、吞吐量等。

稳定性:停机时间、故障恢复、数据一致性、数据备份等。

扩展性:未来可能的变更,以及如何应对变更。

其他:国际化、易用性、合规性等。

以上所有的关注点,和开发资源、时间、范围各个方面,往往很难同时满足,所以必须要明确哪些是关注的重点,哪些则可以有所妥协。例如,为了满足性能要求,可能需要降低数据的一致性;为了合规性,可能不得不花更多开发时间。

对于未来可能的变更,也一定要考虑到。通常情况下,我们至少要考虑未来半年的架构,但可能只实现当前需要的版本,但是确保未来可以很容易的扩展。

一旦确定了关注的重点,在设计和开发的每个过程中,我们都要把这个重点放在心上。

例如,对于订单系统,因为涉及到钱和交易,数据的一致性和可追溯性极其重要。下单和支付的API都必须是幂等的,每一笔收入变动都必须记录日志,必须有严格的核对和对账。为了安全,每一次API调用都必须进行权限验证。

例如,亚马逊有个知名的原则,所有的系统间调用都必须通过定义清楚的 API,不允许共享数据库。这也是一个架构原则。

设计数据库模型

如果分析时有了完善了实体模型,设计数据库模型就不是什么难事了。开发完成后,数据库模型应该以数据库为准,架构文档就不需要保留这一部分了。

需要注意的是,数据库模型是实体模型在关系数据库的实现,但不一定是严格的映射。数据库可能会有范式、冗余、一致性、同步、分表分库方面的考虑,必要时可能会使用非关系型数据库如ElasticSearch、Cassandra等。

有时候还会涉及到数据处理的流程。例如,一张图片提交后可能需要进行预处理,然后有运营人员进行审核和标记,最后进行发布。过程中数据的保存形式或者状态标记可能是不一样的。

数据库设计的更多规范可以参考数据库规范。

设计接口

然后就需要确定 API 细节了。一般我们的服务的 API 是 JSON 格式 HTTP 形式的请求和回调。API 可能是接口定义,也可能会有其他接口形式,例如消息队列等。设计阶段,API 文档可以通过 Markdown 文档、RAP 等记录,开发完成后可以独立维护,或者使用 Swagger 和代码一起维护。

接口设计需要注意几点:

接口的设计应该以系统提供的领域资源或服务为基础,同时考虑调用方的需求。

接口的粒度很重要,太细则调用方很不方便需要多次调用,太粗则无法灵活的满足各种需求,需要仔细权衡。

接口的设计也需要从调用方的角度考虑如何进行调用。必要的话可以画流程图、时序图、状态图详细说明调用顺序即状态转换等。

接口的文档一定要清楚的说明调用接口的方法、前置条件,参数作用、不同条件的处理、返回接口等。

场景实现

一般情况下,有了业务场景分析,有了数据库模型和 API,系统的实现一般是比较简单了。但可能还会有一些细节需要进一步考虑实现细节,以避免风险。可以考虑更细节的活动图、时序图甚至伪代码。例如:

复杂业务场景的详细设计,或者复杂算法的实现描述。

离线任务的执行方式、时间和步骤。

非业务的一些场景,例如网络断开、缓存失效、第三方系统宕机等。

例如,对于支付系统的微信 Web 支付过程,涉及系统较多,交互比较复杂,可以通过时序图来定义清楚:

其他考虑

对于我们的后台系统来说,基本的技术框架都已确定,可以解决很多基础的非业务需求。不过设计系统时,也还是需要考虑以下等方面:

通用处理的方式,例如日志、错误处理、代码规范、单元测试等。

数据迁移、同步和回滚方案:对于老系统的重构,需要仔细考虑并且提前演练。

系统部署和发布:如果系统涉及多个子系统,需要考虑系统的部署架构。特别是同时涉及到数据迁移的,一定要仔细考虑发布的过程。

系统监控和告警:除了常规的监控和告警,是否有特殊的指标需要监控?

并发和数据量:如果系统可能面临对高并发和大数据量的问题, 需要设计对应的方案,以及相关的性能测试和压力测试。

缓存设计:如果需要使用缓存,除了要考虑缓存的选型、方案,而且要把缓存放到整个系统中去进行设计。

技术选型:涉及到新技术的引入时,则需要仔细分析备用技术的优缺点,选择最合适的方案。

设计方法和工具

UML

面向对象设计(OOAP)

领域驱动设计(DDD)

CQRS & Event Sourcing

参考

分析模式:可复用的对象模型(https://book.douban.com/subject/4832380/)

软件系统架构:使用视点和视角与利益相关者合作(https://book.douban.com/subject/24530471/)

UML和模式应用(https://book.douban.com/subject/1792387/)

架构即未来:现代企业可扩展的Web架构、流程和组织(https://book.douban.com/subject/26765979/)

文章

从用例分析到方案评审,我们是如何进行业务系统设计的(http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg)

互联网公司研发RD如何撰写总体设计与详细设计文档(http://www.10tiao.com/html/249/201412/201657741/1.html)

用UML做好系统分析(http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis)

运用四色建模法进行领域分析(http://www.infoq.com/cn/articles/xh-four-color-modeling)

从“四色建模法”到“限界纸笔建模法”(http://insights.thoughtworkers.org/paper-pen-modeling/)

浅谈我对DDD领域驱动设计的理解(http://www.cnblogs.com/netfocus/p/5548025.html)

领域驱动设计参考架构详解(http://blog.csdn.net/bluishglc/article/details/6681253)

领域驱动设计和实践(http://www.infoq.com/cn/articles/cjq-ddd)

我对CQRS/EventSourcing架构的思考(http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027)

架构设计基础知识整理(https://blog.dreamtobe.cn/2016/03/09/oo_architecture/)

作者:章烨明,杏仁医生CTO。中老年程序员,关注各种技术和团队管理。

出处:https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA

架构文摘

ID:ArchDigest

互联网应用架构丨架构技术丨大型网站丨大数据丨机器学习

更多精彩文章,请点击下方:阅读原文

转载请注明原文地址: https://www.6miu.com/read-3849995.html

最新回复(0)