读书笔记: 恰如其分的软件架构

https://book.douban.com/people/fleure/annotation/24872314/

层级和分割

<原文开始>一个关切阻碍了其他关切，这个问题被称为主分解的专横（tyranny of the dominant decomposition）。</原文结束> ## 代码模型 <原文开始>内涵－外延：架构模型和源代码之间最大的不同也许在于，架构模型同时包含了具有内涵和外延特性的元素，而代码只包含外延特性的元素。内涵（intensional）特性使用通用的量词，比方说，“所有的过滤器都是通过管道进行通信的”，而外延（extensional）特性元素是枚举式的，比方说，“系统由一个客户端、一个订单处理器及一个订单存储组件构成”。</原文结束> <原文开始>模型－代码差异：架构模型包含了一些编程语言中没有（也可能有）的抽象概念，比如组件。此外，架构模型还包含了一些内涵式元素，如设计决策和约束，这些内涵式元素根本不能表达在源代码中。</原文结束> <原文开始>了解模型－代码差异，你的第一个反应可能是想避免它。但是，考虑到差异的根源，要想在短期内有一个通用的方案是不太可能的：架构模型是帮助你思考复杂性和规模性的，因为它既是抽象的，又是内涵式的：源代码则是放在机器上执行的，因为它既是具体的，又是外延式的。</原文结束> ## Yanzer 的系统设计之旅 <原文开始>模块之间通过依赖关系关联。两个模块之间的依赖意味着，当一个模块发生变化时，另一个模块也会发生变化。</原文结束> <原文开始>QA 场景对于那些明显可测量的质量属性比较有效，例如，延迟，而对于可维护性和可用性这样的质量属性，效果则没有那么好。</原文结束> ## 质量属性 <原文开始>质量属性通常是自然产生（emergent）的，因为代码里并没有一个地方来直接负责安全性、可修改性、延时等待，又譬如说，可部署性。这些质量是从架构和设计中逐渐浮现出来的。</原文结束> ## 领域模型 <原文开始>领域表达了关于某一个领域永恒的事实。</原文结束> <原文开始>为了避免分析瘫痪，你必须限制领域建模的范围。其中一项技术是，在构建模型前先决定想要模型回答什么问题。</原文结束> ## 软件架构 <原文开始>若要理解某个系统（例如，美国）的架构，就不能死记硬背它的结构，而应该多了解一些相关知识。</原文结束> <原文开始>之所以说骨架的隐喻存在不足，是因为架构并不仅仅是那些外部可见的主体部分（即骨骼），某些不可见部分（如约束）通常更为重要。</原文结束> <原文开始>系统不做什么与系统能做什么同样重要。要确保系统具备特定的质量属性，就必须施加约束，因而行驶路线缺乏灵活性。但是，这种约束却有助于其他的质量要求，例如，车轮与轨道的摩擦力较小，因而可以提高行进速度。</原文结束> <原文开始>Freed Brooks 认为，系统的概念完整性是系统设计的重要目标，因此运用一个始终如一的好主意胜过几个散布于系统各处的奇思妙想。</原文结束> <原文开始>人们过去常说，从来没有人因为购买了 IBM 的产品而被炒鱿鱼。由于 IBM 的大型机系统占据了市场的主导地位，因此也就假设挑选 IBM 的系统是合理的。如今，许多领域都有各自占据主导地位的软件架构，正如 IBM 大型机一度所经历的那样。这正是所谓的推定架构（presumptive architectures）。</原文结束> <原文开始>推定架构之所以能成功，是因为它能够很好地处理领域中的常见风险。例如，信息技术（IT）系统经常要面对的问题包括对共享数据的并发访问、业务规则的变化及需要长期保留的数据，而分层系统能够很好的解决这些问题。一层处理用户界面，另一层处理业务逻辑，还有一层将数据存入事务型（或常见的关系型）数据库。</原文结束> <原文开始>架构提升可以看作是对开发者的一种集权统治，给他们加上了约束的负担，并在统治上保持了官僚主义的作风。或者，也可以把它视为对开发者的解放，还他们以自由，从而使他们专注于功能，而不再是关注于质量属性。</原文结束> <原文开始>从本质上，约束是有用的，它可以体现架构师的决断，促进概念的完整性，降低复杂度，并帮助理解系统的运行时行为。</原文结束> <原文开始>投入架构中的注意力应该与整个系统可能出现的风险成正比，架构的风险越小，改进的空间就越小。</原文结束> ## 概述 <原文开始>开发者把问题分割为规模更小且易于处理的若干子问题，这样他们就可以运用相似问题的知识来解决某些子问题，而且使用抽象有助于他们进行推理和判断。</原文结束> <原文开始>正如 Fred Brooks 所说，世间不存在任何银弹可以瞬时排除软件开发的艰难险阻。然而，应该去寻觅各种武器，以便更好地分割系统、提供知识，并利用抽象来揭示问题的本质。</原文结束> <原文开始>软件架构正是这样的武器。... 它并不是要扼杀创造力，而是使得开发者可应用其创造力去构建规模更大、复杂度更高的系统。</原文结束> <原文开始>开发者施加这些约束，是为了使推导系统变得更简单。...开发者对系统主动施加一些约束，可以增强他们的推理能力。</原文结束> <原文开始>1968 年，Edsger DIjkstra 写了一篇至今仍依旧具有影响力的文章《Goto 是有害的》，文中主张结构式编程。... 今天，回顾这场辩论，很难想象那些持有不同意见者的猛力抨击；然而在彼时，会有如此大的阻力却也不足为怪。开发者已习惯与那套老式的抽象打交道。他们的目光只看到了新抽象带来的约束，却忽略了它所具备的优势；他们揪住那些结构式编程不善处理的问题不放，而实质上，这些问题不过是细枝末节。伴随着每一轮新的抽象观念的诞生，总会有那么一群迷恋骸骨的守旧者，这些人只知道抱残守缺，却不知与时具进。</原文结束> <原文开始>敏捷对于软件开发过程的最大贡献并非设计的抽象，而是提供了一些能够改善设计的技术。</原文结束> <原文开始>just enough architecture：如果能够预见某些风险可以通过重构解决，就可以停止架构设计了。</原文结束> <原文开始>对于封装好的组件或模块，可以自由地改变其内部实现，而不会影响到它的用户。只有封装是有效的，这些组件或模块的构建者才能获得这种自由。</原文结束>