- 内容提要
- 序 1:程序里的世界
- 序 2:最后一层表象
- 关于本书
- 致谢
- 引言:简单的本源
- 篇一:计算系统
- 第 1 章 数,以及对数据的性质的思考
- 第 2 章 逻辑
- 第 3 章 抽象
- 篇二:语言及其面临的系统
- 第 4 章 语言
- 第 5 章 从功能到系统
- 篇三:程序设计的核心思想
- 第 6 章 数据结构:顺序存储
- 第 7 章 数据结构:散列存储
- 第 8 章 执行体与它在执行过程中的环境
- 第 9 章 语法树及其执行过程
- 第 10 章 对象系统:表达、使用与模式
- 篇四:应用开发基础
- 第 11 章 应用开发的背景与成因
- 第 12 章 应用开发技术
- 第 13 章 开发视角下的工程问题
- 第 14 章 应用程序设计语言的复杂性
- 篇五:系统的基础部件
- 第 15 章 分布
- 第 16 章 依赖
- 第 17 章 消息
- 第 18 章 系统
- 篇六:系统的基本组织方法与原理
- 第 19 章 行为的组织及其抽象
- 第 20 章 领域间的组织
- 附一:主要编程范式 及其语言特性关系
- 附二:继承与混合,略谈系统的构建方式
- 附三:像大师们一样思考——从 UML 何时死掉 谈起
- 附四:VCL 已死,RAD 已死
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
18.4 聚焦领域之于系统的主要需求:维护状态或接受消息
答案是:忽略。
忽略掉一部分问题,是我们在系统实施中所必需的策略 2 。除了能降低当前系统与外部系统的耦合关系、减少系统处理异常情况时的成本之外,更重要的一点是,这样的策略有助于我们快速地将问题聚焦到该系统的核心领域。
除开计算机的两个关键问题——计算总量与数据总量之外,我们将领域之于系统的主要需求变成一个简单的定义:计算系统如何应对外部系统的 需要 。而进一步地考察这一需要,就可以发现:在“可计算”方面,任意领域的系统对“当前系统”的需要只有两个,即寻求计算资源,或寻求数据资源。
换言之,任何一个子系统——作为一个更大系统的组成部件——对外部系统只需要承担这样两种责任 3 :
- 维护可对外公示的状态,使得外部系统可以将明确的行为(逻辑)施于自身;
- 接受外部的消息,使得外部可以通过传递数据来影响自身。
对于接下来要讨论的问题来说,“系统由子系统构成”是一个基本设定。更具体地说系统包括 子系统 、 通信 与 验证 三个基础部件 4 ,而本书的下一章将基于这些部件,来讨论与架构实施相关的技术方法,以及通讯与验证相关的问题。
- 其一,看过前言的人应该知道 Joy 是谁;其二,Joy 总是把鸡蛋煮得很熟,这是一种过度的安全措施。 ↩
- 对于灾害,一个简单而实用的策略是:备灾甚于防灾。例如考虑到海底光缆断裂,那么就让 30%的数据通过陆路光缆;考虑到地震频发,那么就将应用分布到不同地区的机房,并在各机房做全镜像数据。这样的措施也被扩展到类似的系统问题上,例如考虑到战争,就将重要的计算资源部署在中立国;考虑到断电,就要增加备用电源,以及设计机械解决方案。但总的来看,这一类措施都是“忽略问题本身”的。 ↩
- 或之一,或全部,取决于系统设计的具体策略。 ↩
- 将 子系统 、 通信 与 验证 作为系统的三个基础部件,是在《我的架构思想:基本模型、理论与原则》一书中讨论架构组成论的一个基础。 ↩
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论