[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程

Posted 文火冰糖的硅基工坊

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程相关的知识,希望对你有一定的参考价值。

第4章 软件架构设计的通用过程

本文给出了进行架构设计的通用过程,每个步骤过程的详细方法,在后续的章节中单独探讨。

4.1 架构设计的实践脉络/步骤

4.1.1 架构设计的三大原则:看需求、把方向、细设计

(1)看透需求

所谓“全面”:特别要注意非功能性需求和约束条件!!

所谓“矛盾”:是相互制约的需求!!

所谓“追溯”:之上而下一棵树,底层的需求一定是源于上一级或上一层的进一步分解,而不是凭空产生,产生孤岛,同时高层次的需求,必须在低层次进一步分解,而不是被忽略。无论是孤岛还是断枝,都不符合追溯的原则。

(2)把方向(容易忽略)

在根据需求,确定详细的架构设计之前,需要根据部分关键性需要,确定好技术方向,并进行粗略的概念架构设计。

概率架构,不关注详细的功能模块和模块之间的接口,它关注的是宏观层面的模块划分以及采用什么样的技术方案选型、设计模式、大的架构等信息。

这个原则是容易被忽略的,特别是非复杂系统,常常被忽略。

但对于一个新设计的复杂系统,把方向是至关重要的!!!它关乎未来较长的一段时间是否需要推翻重来。

从上面的描述可以看出,概念架构主要是面向客户的,详细架构是面向开发者的。

详细架构设计与概念架构设计都是在阐述或描述目标系统,只是粗细程度不同。

(3)细设计:与程序员的接口

详细设计体现在如下几个方面:

  • 视图要全面细致

  • 功能划分要细致

  • 接口定义要细致

4.1.2 架构设计的详细步骤

路径1: 1-》5-》6

路径2: 1-》2-》5-》6

路径3: 1-》3-》4-》5-》6

全路径:1-》2-》3-》4-》5-》6

4.2 架构设计详细步骤分析

4.2.1 需求分析

两纵:功能性与非功能性需求是需求的两大分类。

三横:分析功能性与非功能性需求的三大步骤

  • 范围:需求的边界

  • feature:边界内部的功能特征

  • 上下文:业务场景

4.2.2 领域建模

业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型

它是对业务角色业务实体之间应该如何联系协作以执行业务的一种抽象。

业务对象模型从业务角色内部的观点定义了业务用例

该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例

领域模型不关心业务对象内部是如何实现的。

领域模型:为了更好的解读功能需求和业务用例而建立的对象模型。

领域模型:用图形化的方式描述需求的一种手段,是满足需要的技术方案的可视化展现。

4.2.3 关键需求提取

在复杂系统中,有些需求是次要的,有些需求是主要的,还有些需求是关键路径。

为了尽快验证系统的框架是否可行,需要建立软件系统的原型,而系统的原型就依赖于对关键需求的提取以及基于关键需求建立的概念模型。

关键需求具备如下特征:

  • 关键性的业务场景

  • 关键性的数据处理流程 =》关键性的功能需求

  • 关键性的性能指标 =》 关键性的质量需求、约束条件

4.2.4 概念建模/概念架构设计

基于关键性需求,设计一个简化版的概念架构,有利于在复杂系统完成之前,先建立软件系统的原型,对软件系统的方案进行快速的验证,对软件系统关键性指标进行验证。

备注:

  • 有了概念架构设计,就可以进行编码,完成原型代码的开发。

  • 至于原型代码的开发是程序员实现,还是架构师自己完成,不同的公司做法不一样,有些公司由仿真团队完成,有些公司由架构师团队完成,有些由开发团队配合完成。

  • 概念架构设计并非是必须的:对于简单系统、或已经有丰富的经验、或在已有的复杂系统之上做增量开发,而风险可控,都可能不需要概念架构设计,而直接进行一下步的详细架构设计。

  • 概念架构设计并不指定详细的模块划分详细的接口定义

4.2.5 详细架构设计

详细架构设计,是我们常说的架构设计,“详细”体现在如下几个方面:

  • 详细设计所有可能的视图,包括5大设计视图,15大设计任务

  • 定义模块以及模块之间的详细接口

  • 定义模块与模块之间的详细的交互流程

详细架构设计是软件最终编码实现的输入、是依据,开发团队就是基于详细的架构设计进行后续的编码设计与编码实现的。

4.2.6 架构验证

备注:

  • 架构验证是在概念模型的基础之上的原型验证的进一步验证,是在详解设计完成之后,在正式编码之前,对详细架构设计进行验证。

  • 架构验证不是必须的,它只针对详细架构设计中展现的“风险”进行验证。

结束语

  • 至此,架构设计与验证的主要工作就已经完成,就可以开展后续程序的设计与开发工作了。

  • 后续将对上述流程中的每个步骤单独进行详解。

以上是关于[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程的主要内容,如果未能解决你的问题,请参考以下文章

[架构之路-100]:《软件架构设计:程序员向架构师转型必备》-10-细化架构设计

[架构之路-92]:《软件架构设计:程序员向架构师转型必备》-2-解析软件架构的概念

[架构之路-92]:《软件架构设计:程序员向架构师转型必备》-2-解析软件架构的概念

[架构之路-90]:《软件架构设计:程序员向架构师转型必备》-1-总结

[架构之路-90]:《软件架构设计:程序员向架构师转型必备》-0-总结

[架构之路-91]:《软件架构设计:程序员向架构师转型必备》-1-从程序员到架构师,学习本书的路径