如何做架构设计?

也许您对软件设计存在一些疑惑,或者缺乏明确思路,那么本文将非常适合您。

1、设计很重要

我们可以看一下周边的事物,那些好的东西,他们并不会天然存在,都是被设计出来的,因此设计就是创造和改善事物的重要过程。设计的重要之处在于,最初的设计往往决定最终的结果,甚至决定着事物的长期的发展。例如两个品牌的手机之间,他们可以使用同一个代工厂,但他们差异在设计时就已经决定了。

架构设计也是如此,我见过很多的软件系统,他们经过了很多年的演进,在没有完全重构的情况下,始终无法改变最初设计模样,最初的设计决定了长期的发展。而对于业务深度耦合的系统,重构成本非常高,风险也非常大,变化也更加不确定,所以要更加重视设计。

我们要寻求更好的技术方案,推动架构的良性演进,每一步都是经过深度思考的,而架构设计方法就是帮助我们思考的框架。

通过做架构设计,我们应该提升软件的质量和效率,降低风险和成本。

2、架构设计的目的是什么?

是为了解决软件系统复杂度带来的问题(架构的目标是用于管理复杂性、易变性和不确定性,以确保在长期的系统演化过程中,一部分架构的变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷,让应用的易变部分能够频繁地变化,对应用的其它部分的影响尽可能地小。)

要解决复杂度问题,首先需要识别复杂度的来源,主要集中在以下三个方面:

业务复杂度:流程多,参与者多、状态和变量多等;由业务本身决定,但业务复杂不代表软件系统复杂,例如工作流引擎并不复杂,但他可以做非常复杂的业务,在面对复杂业务时,我们常使用抽象思维,不要让软件逻辑与业务逻辑绑定在一起。

技术复杂度:高性能、高可用、高可扩展、安全,成本、规模等;这部分复杂度常常由技术本身决定,也应该由技术本身解决,通常是采用更合理的框架和工具;避免这些技术特性穿透到应用层。也可以有所取舍,在不同业务情况下,采用不同的实现程度。

设计复杂度:职责不是最小的完备的、概念不清晰的、层次不清的、业务逻辑与技术实现绑定的,组件过多以及关联依赖复杂的;这部分是由设计不合理导致的,也是对业务系统影响最大的一部分,要通过良好的设计来解决。

3、架构设计的主要内容是什么?

找到系统中的元素并搞清楚他们之间关系(如果我们不知道系统是怎么运行的,那么他一定是很复杂的。对于庞大的软件系统,如何才可以被掌控?这就需要将大系统分解为很元素,每个元素需要足够简单,并且元素与元素之间的关系清晰)

软件架构是一种结构,结构中包含了一些元素和元素之间的关系描述;

元素的种类:系统、子系统、模块,组件、服务、类、接口...

关系的种类:层次关系、数据关系、调用关系、影响力关系...

"架构表示对一个系统的成型起关键作用的设计决策,架构定系统基本就成型了,这里的关键性可以由变化的成本来决定。"-- Grady Booch.

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch.

4、架构设计有什么原则?

合适原则:“合适优于业界领先”。 真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。

简单原则:“简单优于复杂”。 优先使用直接的不复杂的方案解决问题;

演化原则:“演化优于一步到位”。软件需要根据业务的发展不断地变化,架构要不断地在实际应用过程中迭代,在某个阶段必定有所取舍,但架构的演化必须是低成本的,当业务发生变化时能够最高效的迭代;在这个过程中修复缺陷的设计,积累优秀的设计;

5、架构师的职责是什么?

业务分析:梳理对业务和技术的理解和判断、形成业务领域知识、明确的业务目标和本质的业务诉求;

系统建设:降低系统复杂性、规划系统远期架构、推动架构的合理演化;

技术方案:选择合适的技术、提供对业务的解决方案,把控全局,包括质量、效率、成本、风险;

关键问题:攻克难点,解决关键问题,指导研发落地;

知识沉淀:以体系化的表达方式,面向不同人员的视图语言,持续完善知识系统;

6、架构设计过程如何?

过程:全局分析业务 → 设计方案 → 概要设计 → 详细设计 → 补充设计

视角:业务级 → 系统级 → 应用级 → 模块级 → 技术级 → 代码级 → 实施级;

架构师的协作链路较长,每一个过程都应该留下资料,越下游的角色往往需要更全面的资料;架构设计文档应该包含架构师参与的所有环节,以及这些环节产生的图文说明;不仅仅是空洞的结果,应该包含架构师的思路和想法;

全局分析阶段

这阶段需要对业务需求进行全面分析,需要将名词罗列出来,区分名词是功能、流程、名词、参与者的哪一种。再通过分析业务的本质并找到其中的关键名词,关键的名词被称之为领域,可以围绕关键的领域构建业务模型;

在这个过程中,需要统一语言、识别核心领域、按照相关性将功能归属到对应的领域,对领域之间的关系做出必要的描述,输出物是名词与解释、领域以及拥有的能力,业务架构。

名词的概念必须是清晰的,领域的职责必须是明确的,领域拥有的能力必须是相关的;

其中业务架构可按照场景层、功能层、领域层、依赖层划分,例如下图;

设计方案阶段

在完成全局分析之后,我们应该设计技术方案,尽可能提供多个备选方案的图文说明。需要对备选方案做充分的优劣分析,最终取舍一项最合适的方案,没有被选择的方案(或者取舍的部分)也要被说明;

我们需要找到各项约束条件(时间、人力、硬件等),评估在约束条件允许的情况下,哪个备选方案更合适,我们可能考虑如下方面:

方案对业务影响:主要判断需求覆盖程度、实现业务的短期目标、考虑业务的长期目标;

方案的技术需求:安全是否满足、性能是否满足、规模是否满足、可维护性;

方案的可扩展性、方案的复杂程度、方案是否能够演进、方案演进成本如何(高成本的 慎重考虑)、方案的影响力传播如何(对上下游影响较大的 慎重考虑);

架构设计阶段-应用架构

用以说明当前系统的元素(系统、子系统、模块,组件)以及他们之间的关系(层次关系、依赖关系)

重点是将可复用的组件抽象后下沉,越往下层越是稳定和通用,由上层承接不稳定的业务;

应用架构图体现了层次关系,以及不完全体现了依赖关系,依赖只能是上层依赖下层,示例如下图

架构设计阶段-部署架构

用以说明支持应用所需要的硬件能力、以及外部中间件、网络、机房等情况;可参考下面两张图;

架构设计阶段-数据架构

描述数据资产结构、存储、流转、灾备的情况;最常用的是ER图;

架构设计阶段-技术架构

描述一些关键技术的说明,比如性能、安全、交互等;

描述技术选型和代码框架的说明,比如DDD推荐的菱形对称架构,文字和图片描述都可以;

详细设计阶段

详细设计是对质量的把关、是对研发落地的指导;

这部分涉及的内容较多,比如服务、事件、接口、实体和值对象、时序图、数据库设计等等;

领域服务、领域事件

时序图

实体关系图

7、有什么方法能做的更好?

学习和使用领域驱动设计,使用正确的方法梳理和理解业务,并落实到架构过程;

尽早的介入,从业务领域建模和在产品方案阶段介入、推动领域知识的传递、为后续做好铺垫;

积累业务能力和洞察力,需要识别关键部分与辅助部分、预料可扩展部分与不变部分,识别水平能力与垂直扩展;

对于架构设计产物,不要只画图,多辅以文字表述图中内容;

8、还需要掌握什么知识?

业务知识:业务架构(是对当前业务、领域、能力、流程、参与者、场景的介绍),现状架构(是对当前架构的描述,可以包含应用架构、技术架构、部署架构、数据架构等),愿景架构( 是架构应该演进到的完美情况),存在问题(现在面对的痛点、无用部分、缺陷部分)

高性能:多线程、队列、缓存、分片、异步化,前置化、静态化、预处理;

高可用:限流、降级、冗余、灾备、回滚、灰度;

扩展性:多态、防腐,依赖反转(业务身份、扩展点、SPI),抽象化(比如流程引擎、规则引擎等)、事件驱动、设计模式;

本文部分图片来源于互联网

作者:京东科技 董健

来源:京东云开发者社区

热门相关:超武穿梭   夫人,你马甲又掉了!   豪门重生盛世闲女   修仙界最后的单纯   豪门重生盛世闲女