软件架构设计理论
2021-10-21 17:40:04 2 举报AI智能生成
软件架构设计理论
作者其他创作
大纲/内容
业务功能需求、用例
质量属性、肺功能需求
企业限制、架构策略
企业级需求的决策体现
What
高内聚
低耦合
（自顶向下功能分解）使用已有的基于模块的内聚和耦合技术
功能分解
选择架构风格来实现质量和业务需求
选择架构风格
描述软件元素在共享服务和底层构造的基础上，如何进行和交互
定义软件模板
清洗定义迭代的每一个步骤
递归迭代
ABSD方法论
功能需求和用例
质量和非功能需求
限制和企业策略
架构的真正驱动
Why
（需求库）需求获取
生成类图
对类进行分组
将类打包成构件
标识构件
需求评审
架构需求
提出架构模型
映射构件
分析构件相互作用
产生架构
设计评审
架构设计
架构文档化
复审后的文档化架构
架构复审
分析与设计
构件实现
构件组装
构件测试
构件库
架构实现
需求变化归类
架构演化计划
构件变动
更新构件的相互作用
架构组装和测试
技术评审
演化后的架构
架构演化
ABSD具体实现
How
银行海外分行拿到证券牌照
业务背景
红马甲交易、网银查询、分红派息T+1结算、银行监管核算
功能需求
99.95%高可用
肺功能需求
网银、交易所前置
渠道层
日间交易模块、共享数据库、夜间批处理模块
领域层
交易监管网关、交易核算网关
内部渠道层
整合交易大型机
银行核心层
银行遇到新的挑战-证券业务
证券业务架构
案例分析
架构设计方法论（如ABSD的需求、设计、文档化、复审、实现、演化）
题眼
能将设计原则、架构风格和演化过程描述清楚
加分项
题目1：对于新业务，如何完成一个完整的架构设计流程？
需求驱动论（功能、质量、限制）
能结合实际项目，描述如何根据需求选择风格和模板
题目2：如何在架构设计中选择合适的软件风格和软件模板？
理解“包含”、“扩展”、“泛化”等基本关系
能结合UML图来描述和分析
题目3：在一个订单输入子系统中，创建新订单和更新订单都需要核查用户账号是否正确。用例“创建新订单”、“更新订单”与用例“核查客户账号”之间是什么关系？
ABSD基于架构的软件开发
建立领域模型
领域分析图
领域分析方法
领域分析
获得DSSA、
领域设计
开发和组织可复用信息
领域实现
DSSA基本活动
产品经理-需求规约、领域字典
领域专家
系统分析员、产品经理、企业架构师
领域分析人员
应用架构师、自身程序员-软件重用和领域设计
领域设计人员
老带新模式
领域实现人员
DSSA人员分工
DSSA方法论 – 特定问题域的应用模型
目标场景
领域具有普遍性、抽象性、重用性
定义领域范围
定义领域特定的元素
定义领域特定的设计和实现需求约束
定义领域模型的架构
产生、搜集可服用的产品
DSSA创建过程
领域开发环境
领域特定的应用开发环境
应用执行环境
三层环境模型
分析、设计、实现、迭代
搜索可复用元件
产生可复用元件
进一步升华-螺旋形迭代
技术文献
成型软件
用户-铁杆粉丝
专家建议-退役球员
未来需求-合作球队
领域分析的输入
管理机制
领域方法-事件风暴
方式
领域实现人员-老中青
领域设计人员-应用架构
领域分析人员-其他架构
领域专家人员-产品经理
人员配置
分类方法-子域分层
标准（质量、约束）
功能模型（类图、ER图）
领域语言
领域分析的输出
数据仓库
数据湖
数据广告
数据平台
机器学习
数据模型
训练、预测
数据科学
API网关
设限
CDN
负载管理
广告
内容
内容管理
短信
微信
通告
消息
消息通告
VPC
云服务
基础架构
搜索
作业
消息队列
应用平台
合并
测试
自测
质量保证
发布
集成发布
日志
链路追踪
遥测监控
法务要求
合规审计
通用支撑子域
购买
支付
履约
供票
市场
风控
客服
发现
对账
产品
定价
核心子域
票务领域分层
票务领域分析方法
国际电商平台架构
人员分工
架构师沟通
架构师职责
组件和决策
能结合特性方法论（ABSD、DSSA、AT等）
题目1：请描述一下你在大型架构设计中的职责，以及如何和其他部门同事配合的？
领域驱动模型
DSSA领域架构开发方法
能将业务映射到领域，并能复用现有的架构元件
题目2：请描述一下对于领域架构的理解
领域驱动模型，本公司核心域DSSA软件架构
能将所在行业的领域DSSA软件架构解释清楚
题目3：请描述一下你们公司的业务模型
题目4：风向一个你用过的领域相关的架构设计方法，对比一下和DSSA的思路有什么不同？在不同场景下应该如何取舍更合适？
DSSA特定领域的软件架构开发
功能性需求（用例说明）
组件模型
非功能性需求（质量）
非功能性需求（限制）
运行模型
需求驱动
z轴应用、技术选择
x轴逻辑、物理实现
Z轴功能、运行模型
架构立方体
多视角
OpengGroup认证
软考
认证考试
方法论分享
画图环节
面试
快速理解公司架构
快速开展项目设计
快速开展项目迭代
试用期
使用场景
AT方法论
对接UML模型语言
对接RUP统一过程
真正可以和UML模型语言、RUP统一过程对接的方法论
需求文档-质量
降低维度
多维度架构设计
电力行业案例
先看一个案例
视角与视图
能结合实际案例，分析多视角架构设计思路
题目1：你在架构设计中通常采用什么方式来描述软件架构
用例与质量场景
能结合实际案例，分析如何妥协用例和质量要求
题目2：你在架构设计中采用什么方式来描述需求？
AT架构思维
代码包
模块
领域
CBM
SOA
组件组成
就是描述计算组件与组件的交互
软件系统架构
拆解
定义
关联
画图与实现
架构图举例
少林-组成派
架构的真谛是架构决策，是智慧和思维
决策山上有真人
是由一个个决策组成的有机整体
根据需求
限制决定技术
架构和实现
武当-决策派
软件架构的定义和两派之争
元素
接口
子系统
协作
风格
BA大师
处理元素
数据元素
连接元素
P大师（鲁棒图）
决策
方向
过程
W大师
组件是眼
决策是手
个人观点
架构设计大师
软件架构的定义
从“产品”听众获取灵感
桥梁
指引“研发”乐队完成演奏
指引
将长篇大作切割成乐章
分割
将乐章和声部交叠协奏
交互
在思考中挣扎，在决策中完美
G小调第40交响乐-悲凉中前进
演进
案例：IT界的莫扎特
软件架构目的
C
Java
Python
Go
语言
数据结构
设计模式
算法
结构设计
UML
统一建模
软件架构的过去
逻辑
物理
应用
技术
功能
部署
ABSD
DSSA
AT
体系架构
软件架构的现在
IaaS
PaaS
SaaS
云化-资产复用
拆迁者
修缮者
绞杀者
演进式架构
软件架构的未来
软件架构的发展阶段
工作广度
组成与决策
莫扎特的6大作用
方法论完整
新架构框架
新技术框架
题目1：日常工作主要有哪些？
学习能力
知识系统
体系书籍
新技术书籍
大师互动分享
题目2：作为架构师，有什么推崇的书或者大师？
案例深度
决策派思路
从莫扎特6大作用出发
决策依据
理论->实际->理论
题目3：你在架构设计过程中碰到的难点？
软件架构概念
设计决策的体现
系统设计的约束条件
组织结构的映射
DevOps的实现
循序渐进的演进手段
可传递可复制的模型
跟随业务发展、扫清技术债务
业务
架构向前演进、向后兼容
架构
技术成熟度、复杂度、买还是建
“架”起到需求到落地的桥梁
“构”建IT新蓝图
应用关联：意大利面
软件发布：跑火车
一个电商的实际例子（早期）
CDN缓存
蓝绿部署、
一个电商的实际例子（中期）
云平台
弹性扩缩容
云存储
批处理
调度
大数据平台
一个电商的实际例子（后期）
架构落地的保障
交流在哪里？
技术专家
通用语言Ubiquitous language
沟通配合
语境不同
依据原因
立场不同
决策派，一堆人来进行决策
召集所有人，防止单向沟通
渠道失真
项目干系人的沟通交流的手段
沟通
全世界第一款省下100万广告费用
优势
需要研发手机壳套探测器，软硬件开发费用预估1000万
劣势
打入粉丝群，捕获无脑脸控
机会
有被XXX抄袭的风险
威胁
SWOT分析
资源统一管理，多架构并存，快速上手，部署比较快
不适合混合云，文档相对较少，功能覆盖不全
云大数据融合，新的调度架构
风口变化，K8S江山一统
Mesos Marathon SWOT分析
混合云模式，技术普及率，存储管理，弹性伸缩
仅为容器服务，安装相对复杂，大数据场景
江山一统，业界标准
风口变化，Serverless
Kubernetes SWOT缝隙
负责人拆分
拆分到小组
拆分到人
按照数列拆分任务
R-执行人，A-负责人，S-支持者，C-顾问，I-知情人
RASCI决策矩阵
ADMEMS矩阵
RAID矩阵
性能
可用性
扩展性
安全性
耦合性
五点核心
易用性
伸缩性
可移植性
可维护性
相关核心
可操作性
可重用性
非核心
质量核心
系统质量属性
约束
对于复杂的，需要协作完成的系统开发，沟通是必须要持续提升的问题。每个团队由5-10人组成（沟通成本 = n(n-1)/2 - 《人月神话》），在团队内部进行频繁的、细粒度的沟通。对于团队外部，定义好接口，契约，只进行粗粒度的沟通。这样可以降低沟通成本，同时也符合高内聚，低耦合原则（代码和人员管理有些时候真是相通的）。
第一定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization线型系统和线型组织架构间有潜在的异质同态特性
这就是我们在用kanban管理迭代时几乎都有一列是BAU（Business As Usual ），其中会包括一些日常修复的Bug Story。敏捷开发中将迭代引入，做到持续交付，快速验证，迅速反馈，持续改进。
第二定律
大白话就是，你想要架构成为什么样，就将团队分成怎样的结构。比如前后端分离的团队，架构就是基于前后端分离。在基于微服务设计的团队里，一个很好的理念是自管理。团队内部对于自己所负责的模块高度负责，进行端对端的开发以及运维。
第三定律
合久必分，分久必合，团队以及架构都是在不断优化的。一个团队随着人员的增加，沟通以及管理成本一定会增加。
第四定律
康威定律
“两个披萨原则”有助于避免项目陷入停顿或失败的局面。领导人需要慧眼识才，找出能够让项目成功的关键人物，然后尽可能地给他们提供资源，从而推动项目向前发展。让一个小团队在一起做项目、开会研讨，更有利于达成共识，促进企业创新。
贝佐斯的两个披萨原则
组织
保留原有的迁移到新的位置，很难实施，直接重构
拆迁者模式
被寄生者死亡，寄生者替代存活
绞杀者模式
追加新的功能，逐步替换，一直到全部替换完成位置
修缮者模式
原子vs整体适应度函数
触发式vs持续式适用度函数
静态vs动态适应度函数
自动vs手动适应度函数
临时vs预设适应度函数
适应度函数
ABSD、DSSA、AT、EA、TOGAF
方法论复用
UML、SOA、CBM
模型复用
素材、图片、表格、图标、文件
工件复用
三七原则，保留30%就很高了
剪裁
内部资产库、外部架构社区
资产更新
复用
开发、OA和生产的不匹配
如何解决环境问题
凤凰项目和传统系统耦合
如何解决耦合问题
关键人员疲于再多个项目中切换
如何解决资源共拥问题
突发性业务需求、性能测试需求
如何满足峰值需求
最小代价完成安全合规审计
如何解决安全问题
DevOps凤凰传奇
或者国内的软考高级架构都是一样的
广度
知识点
笔试
TOGAF企业架构
应用架构
数据架构
集成架构
技术架构
Master Architect主架构师认证
需求
设计
风险
解决
三个完整方法论案例
20+架构师评测点（各2-3个案例论证）
评测重点：方法论、模型的复用，架构资产的贡献
考试过程
OpenGroup认证
How-案例分享
语境、立场、沟通渠道处理，架构决策
决策派
通用语言
RASCI决策
题目1：作为架构师，遇到部门冲突如何解决？
耦合度
质量
多角度分析
实际案例侧重点清洗
题目2：作为架构师，平时的设计重点关注哪些因素？
解决技术债务
架构演进策略
多模式使用（拆迁、修缮、绞杀）
冲突预防
题目3：作为架构师，如何处理新架构和老架构之间的冲突？
题目4：作为架构师，挑选一个你的实战项目，，描述该应用架构如何随着组织架构的变化而演进的？
题目5：挑选一个项目，描述项目中你如何挑选、复用和剪裁合适的架构设计架构、设计模式、架构风格、软件包？
软件架构理论
DevOps凤凰项目
OpenGroup架构师认证
证券业务案例
国际电商平台案例
只有当前一步的计算任务处理完成后，后一步处理才能开始。计算任务前后顺序明确。
强时间顺序
数据传送在计算单元之间通过指定的数据交互方式传递。每一步要确保数据完整，才可以向下一步发起数据传送。
强完整性
有独立的顺序控制和时间把控机制，并辅以数据检查等功能。
强控制力度
比如银行的夜间批量结算和大小额清算，券商的夜间交易结算和证券系统对账等。特点是通常运行在指定时间，数据流庞大，每一步有精确的数据处理要求和校验机制，顺序逻辑清晰。
传统定制批处理任务
Hadoop在处理过程中有明确的步骤安排，比如map几次，shuffle几次，再reduce完成数据处理。
Hadoop大数据处理
当前比较火的批量处理工具是Apache Beam。虽然它同时支持批处理和流处理，但是在日常使用中其批处理的优势更加明显。它定义类专门的数据集、计算过程、管道和执行器。能够形成有向无环图，来保证数据流的方向和结果输出。
Apache Beam大数据处理
经典案例
批处理Batch Sequential
是其中的核心构件，负责业务的处理。它从用户或者上游管道获得输入数据，进行数据的变换及增量计算，处理完成后，通过下游管道传递给另一个过滤器。过滤器是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的其他过滤器信息。
过滤器
是一种数据传输途径。可以是Unix/Linux操作系统的管道文件，也可以是消息队列，只要能确保数据的先进先出，单向进出就可以了。
管道
在编译器系统中，一个阶段(包括词法分析、语法分析、语义分析和代码生成) 的输出是另一个阶段的输入，处理阶段是是以数据流进行编译过程驱动流转的。
编译器
比如经典的Linux命令\"ps -ef|grep java\"，就是在系统中检查java进程信息，其中的”ps -ef“和”grep java“就是两个过滤器，各自处理相关流程步骤，中间的\"|\"标识，就是管道，负责在两个过滤器之间进行有向传输。
操作系统管道过程
比如经典的Spark Streaming、Storm、Apache Flink、Kafka Streams等流式处理框架，或者是完整的流数据管道式处理方式，或者是将数据流进行微小的窗口切分，再采用超小批量处理方式进行数据处理和向后传递。
Streaming流处理
管道-过滤器Pipes-Filters
数据流Data Flow
类似福特流水线的优势，它将每个阶段的处理过程进行了隔离，使得软件构件具有良好的隐蔽性和高内聚、低耦合的特点; 每个批处理过程或者过滤器独立管理，可以方便地进行替换。
解耦
支持软件重用，只要提供适合数据处理的需求，任何两个批处理过程和过滤器都可有序被连接起来。
数据流风格在5大风格中是最适合大数据的架构风格。它可以完成各种大量数据互通、传递、处理的过程。
同时，批处理序列风格与管道过滤器风格的不同点也很多：
高吞吐
批处理通常由时间规划和任务调度统筹安排；而管道过滤器是递增式处理过程，是由数据驱动的处理流程。
计划性
批处理需要完成前序任务，再进行后续任务，通常整个任务处理周期较长，通常以分钟、小时、天为单位；管道过滤器在传输过程中没有整体处理的概念，可以快速将一份小的数据变动流过相关的过滤器和管道，实现秒级、分钟级的快速响应。
敏捷性
数据流两种风格的相似点
数据流风格
主程序/子程序风格是面向过程的经典架构风格。一般采用单线程控制，把问题划分为若干处理步骤，分别由主程序和子程序完成。主程序调用子程序，子程序将调用结果返回给主程序。同时，子程序通常也可以合成为模块，增加调用过程的层次性。主程序最终结果的正确性，取决于其下属的模块和子程序的执行结果。
符合传统的商业行为过程：浏览->添加购物车->购买->支付->收货->评价等。
简单明了
可以和程序流图、泳道图、状态机模型等架构图一一对应，方便开发和验证。
架构清晰
主程序-子程序Main Program-Subroutine
这种风格是主程序子程序风格的进化，它随时面向对象语言的产生而同步出现。它将数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。由对象来负责保持资源的完整性（成员变量）和程序之间的过程调用关系（方法）。
每个对象独立负责维护其本身的完整性，比主程序子程序的紧耦合方式，更容易实现应用体完整性。
完整性
对象的表示对其他对象而言是隐蔽的，对象可以不影响它的客户就能改变其实现方法。
隐蔽性
可以充分利用高级语言的优势来实现封装、聚合、继承、接口、多态、依赖、抽象、复用等特质。和现实生活中的实体逻辑可以一一映射地进行实现。
面向对象编程的优势
面向对象Object Oriented
分层是软件架构设计的主流方法之一，将应用设计成一个层次系统，每一层为上层服务，并作为下层客户。每一层最多只影响上下两层，同时允许每层可以用不同的方法来实现应用逻辑和功能。这对于解决软件的复杂性和重用性，提供了强大的支持。
但它们有一个共同点，都采用了层次化的描述方式，所以可以 看成是层次结构风格的延伸。
每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层
邻居互动性
每一层可以独立设计、开发，只要满足和上下层的接口定义即可。 同一层可以实现架构重用和借鉴，从整体上将应用实现了分层解耦。
隐藏复杂性
确保每一层可以采用不同的技术栈和设计思路，所有数据会根据网络层次结构进行数据包的封装，不会出现层次的跳跃现象。
OSI网络7层模型，TCP/IP网络4层模型
操作系统从核心的内核层，到外围的工具、用户系统，类似一个洋葱模型，层层包裹。所有的过程调用只在相邻两层之间进行
操作系统内核和用户态管理
比如MVC三层模型、领域驱动4层模型等。我们将在后续的领域 驱动章节详细介绍4层领域模型。可以想见，层次结构风格极大化地抽象了软件架 构，摆脱了编程语言的限制。其他如C/S、B/S、SOA应用架构等，横跨了软件、 系统和网络范畴。
应用分层模型
调用返回风格是5大架构风格中最润物细无声的一种。它几乎自然而然地被运用在了所有开发设计过程中： 在面向过程的开发中，通常都采用了主程序/子程序风格 在面向对象的开发中，几乎都是用了面向对象风格 在应用的分层设计中 几乎都采用了层次结构风格
层次结构Layered
调用-返回Call Return
调用返回风格
主要强调系统中的每个构件都是相对独立的个体，他们之间不直接通信，以降低耦合度，提升灵活性
远程通信具有清晰的指向性，目标明确
目标明确
通常以同步调用为主，辅以异步交互式通信方式
同步为主
通常采用同步或者异步方式，远程调用其他模块的接口程序
应用之间的RPC调用
通过规定的消息传输机制（REST接口规范）来实现同步或异步方式的进程间通信
应用之间的RestAPI调用
比如区块链、BitTorrent等的点对点通信，也是进程通信风格的延伸
点对点通信
进程通信Comm Processes
事件驱动风格是基于事件的隐式调用风格，构件不直接调用一个过程，而是触发或者广播一个或者多个事件。后续执行过程会被注册在一个或者多个事件，当对应的时间被触发或者广播时，系统会自动调用该事件中注册的过程，执行相应的模块功能。
通常以同步调用为主，辅以异步和交互式通信方式
事件的触发者并不知道哪些构建会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些谷草恒会被调用，体现了极强的低耦合性
隐式调用、匿名互动
通常事件驱动的接受者不止一个，会采用广播方式进行信息传输，方便实现一对多的过程调用和应用交互
广播机制
在IDE工具中设置断点，当触发断点后，IDE工具处理程序在断点出停下，变量监视器自动刷新变量数值。整个过程IDE工具和调试模块之间没有直接的进程通信，而是采用事件驱动的机制实现过程调用。
调试器
消息队列常用于应用间的通信和业务流的削峰填谷，当消息被发送到消息队列后，对应的消息监听会自动消费该消息，并进行相应数据和业务处理操作。整个过程中消息的生产者和消费者之间没有直接的互动和了解，完全有消息队列来驱动数据流的指向。
事件驱动设计（Event Driven Architecture）是当今很火的话题，结合CQRS读写分离等技术，可以实现完整的业务分解和设计。
事件驱动设计（后面DDD会介绍）
可以是点对点的、制定方向的进程通信风格；也可以是广播、饮食调用的时间驱动系统风格；两者结合起来真正的实现了进程与进程、模块与模块、系统与系统之间的互动
事件驱动的系统Event Systems
独立构件Independent Components
独立构建风格
完整的解释工作的解释引擎、被解释代码的存储区、记录解释器引擎当前工作状态的数据结构、记录源码被解释执行进度的数据结构等。解释器可以方针硬件的执行过程和一些关键应用，通常被用来弥和程序语义与硬件语义之间的差异，其缺点是执行效率低。
提供虚拟运行环境
虚拟环境
解释程序代码、运行状态等
程序解释
如Java语言的JVM。他负责Java语言的解释和虚拟机运行环境。
编程语言执行器
像Docker Daemon等容器运行环境，也可以理解为容器的解释器和虚拟机，完成了自定义容器内应用的解释和管理
容器运行解释器
电路前端后端仿真运行环境，负责解释电路设计程序，并提供运行仿真环境
CAD仿真环境
基于经验的大数据推理步系统。将专家推理逻辑和程序，转换成决策平台的解释器系统。
专家系统
解释器Interpreter
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存等
规则的细节被引擎所解释，来决定业务、监控等策略和措施的制定
规则决策
简化人工智能、加速自动化和逻辑处理
人工智能
像Drools开源规则引擎、IBM iLog商业规则引擎，都是业务人员的好伙伴。业务人员不能像程序员一样精通if/else逻辑开发，但是又需要可以随时进行业务逻辑的修改和优化。业务规则引擎提供了有效的途径，它可以采用图形化的方式，让业务人员拖拖拉拉地制定业务逻辑。比如优惠券的计算逻辑、产品的价格制定逻辑、仓储系统的内部流转逻辑等
业务规则引擎
大数据分析通常满足八二原则，80%的数据分析仍然是有规律可循，可以采用一定的规则引擎来处理，另外的20%数据才需要AI人工智能的强大分析能力来完成。在规则话的处理过程中，通常数据科学家不会直接编程来完成逻辑规则的指定，所以大数据环境，分析规则引擎也被广泛使用，来协助数据工程和数据分析
大数据分析引擎
比如WAF应用防火墙、机器人识别防护、IDS/IPS入侵检测和防御，通常都依赖于规则的设定
网络防护系统
在IT运维和数据中心运维中，越来越多的采用了规则类的工具和系统来实现自动化
运维自动化
基于规则的系统Rule Based System
虚拟机风格是偏重运行环境的一种风格。她描述了在一个应用系统中，程序里面是如何被解决和用于决策的：虚拟机方式提供解释引擎和中间数据存储过程规则引擎来匹配和解释规则集，指定最终决策
虚拟机Virtual Machines
虚拟机风格
别名也叫作以数据为中心的风格，可见它关注的重点是数据的存储和共享方式。仓库有两个核心构件：中央数据单元和独立构件。中央数据单元存储和管理所有数据和系统当前状态；独立构件通过和中央数据存储交互，来执行逻辑处理
数据库架构师仓库风格常见的形式，所有的关系型和非关系型数据库都可以归为这一风格。它有一个中央数据库或者数据仓库，作为数据共享数据源，保存当前系统的数据状态；大量的风不是和不同业务逻辑的系统，作为独立处理元素，对数据元素进行操作
集中式的共享数据库
共享数据源
分布式的独立处理节点
独立处理单元
数据库DataBase
超文本系统风格主要用于共享静态网页
超文本系统可以是集中的文件资源方式，也可以是网状互通的分布式资源共享方式
多重共享形式
适合管理非结构化文件，入静态文件、对象存储等
非结构化文件
保存有JS、CSS、Html的话静态网页，用于让不同领域的前端节点来共享的访问静态页面元素和架构
CMS内容管理系统
节点个子存储部分文档，通过节点跳跃、网状链接等方式共享静态文件
分布式文件互通
超文本系统Hypertext System
黑板是所有软件架构风格里最复杂的一套风格。通常只在特定领域使用，比如语音识别、模式识别、信号处理等。
黑板系统是一种问题求解模型。以语音识别为例，通常一段语音的识别没有必然正确的最优解，只有根据现有知识和模型的匹配近似解。将原有问题通过变换、分割等方式转换为多个子问题，并将原始数据也相应地转换为高级数据结构。1000个人心中有1000个哈姆雷特，同样地，1000个专家（或专家系统）也会有1000个不同的子问题解。用一个黑板，让这些专家将已经获得的信息、已经处理完的数据、已经完成的子问题都写到同一个黑板上。其他专家可以通过这个共享的黑板的数据变更，很快地作出反应，优化自己手上的子问题计算。
这个黑板，就是用于记录组织推理步骤、控制状态数据和问题求解之领域知识的框架。它将问题的解空间组织成一个或多个应用相关的分级结构。这些分级结构将由不同的专家（系统），通过不同知识表达方法、推理框架和控制机制的组合来形成各自的知识源。知识源之间没有直接的数据传输，所有交互都通过共享的黑板的数据更新来完成。
不同的子问题采用不同的数据集、推理框架和控制机制，生产分布式的知识源。
分布式知识源
通过黑板这个集中式逻辑系统完成所有知识源的数据共享
集中式的数据共享
通过黑板的数据更新，通知各数据源，从而驱动分布式计算的进行
集中式控制
黑板Blackboard
仓库风格是5大架构风格中，最偏重数据共享的一种风格。它描述了在一个应用系统中，数据是如何被分布式系统所存储和访问的：数据库风格做通用的数据集中式共享方式。超文本系统用于静态文件的共享。黑板用于信号处理等特殊领域的知识源的共享，和子问题解的流程驱动。
仓库Repository
仓库风格
主流软件架构风格
风格影响架构质量和实现效率
理论结合面试题实战
理解“事件驱动”软件架构风格
能结合注册事件处理和回调函数进行深入分析
题目1：Windows操作系统在图形用户界面处理方面采用的核心架构风格是什么风格？
理解“虚拟机”软件架构风格
能结合Java解释型语言、JVM原理，进行深入分析
题目2：Java语言宣传“一次吧编写，到处运行”的特性，从架构风格上看符合什么风格特点
理解“管道-过滤器”软件架构风格
能结合Web服务器在数据传输上的协议分层原理，进行深入分析
题目3：如果要开发一个web服务端处理软件，对客户端请求消息进行解析与处理，包括HTTP报头分离、SOAP报文解析等功能。采用什么架构风格，最合适该服务端处理软件
讨论题目1：某公司承接了一个开发家用空调自动调温器的任务，调温器测量外部空气温度，根据设定的期望温度控制空调的开关。根据该需求，你认为公司应采用哪种架构风格最为合适
讨论题目2：某游戏公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和之间的关系。针对该目标，公司应该采用架构风格最为合适？
软件架构风格
软件架构设计
0 条评论
下一页
