软件架构终归属于工程学的范畴，不能一概以“只可意会不可言传”来搪塞，因为架构知识是可以传递的，架构文档是可以共享的，最重要的是，架构自身是可以评审、验证与实现的。
架构的盛宴
Stephen J. Mellor在《架构之美》序中，画龙点睛地勾勒出美丽架构的模样，即必须遵循的一些普遍原则，分别为：
- 一处一个事实
- 自动传播
- 架构也包含构建
- 最少量机制
- 构建引擎
- O（G），增长的阶
- 抵制熵增
这些原则，其实就是架构师的智慧，没有足够深刻的理解与深入实践，是不可能给出如此言简意赅的架构建议的。按照我的理解，这些普适性原则其实就是在说明所谓美丽的架构，就是简单、一致、适应变化并能去除重复的架构。其实，泄露天机的一句话还是Mellor所言——美丽的架构用更少的机制做更多的工作。这就是《架构之美》一书不凡的开篇了。
若是一本平庸的书，必然会惧怕这样精彩绝伦的序，因为它愈发的美，就愈发能照映出正文的丑；它愈发的言之有物，又愈发会衬托出正文的空洞无味。 然而，若是内容也是如此的精彩绝伦，那就无异于锦上添花，珠联璧合了。通透点儿，就是齐活！这就好比一首歌曲的领唱者，倘若一开始就飙出高音，声入云霄。跟唱者没有点儿本事，恐怕就难以为继了；可要都是高手呢？那就真是一场音乐的盛宴了。
《架构之美》合唱团荟萃了全球最为顶级的那部分架构师，所以说本书是架构的盛宴，似乎也不为过。
论架构
让我们先看看本书的第一部分《论架构》。
第1章《架构概述》延续了序言的高屋建瓴，全篇介绍了架构师的角色、软件架构的含义、架构结构，并展示了什么才是好的架构，美丽的架构。虽然仅仅是一些概念的阐释，却仍然不乏真知灼见。例如在本书1.2节，给出了创建软件架构的如下意见：
- 软件架构师的首要关注点不是系统的功能；
- 考虑折中；
- 运用“分而治之”的架构原则；
- 概念完整性是架构最重要的特征；
- 一份更完整的清单；
- 架构会影响组织架构。
第2章《两个系统的故事：现代软件神话》的角度又有所不同。首先它注重实例，讲述了两个软件城市的故事；其次它突出对比，比较了混乱大都市性质的项目与“设计之城”。对比是最好的老师，如果你茫然不知一个系统究竟好在哪里，坏在哪里，通过引入对比，一切的好与坏都被放大，且清晰无比地被标示出来。
Pete Goodliffe运用隐喻将设计看作是城市的规划与建设，有效地促进读者的理解，加深了整体认识。本章给出了设计的反模式与模式，引导我们对自己过往的设计进行反思，进行印证。例如，本章图2-4给出的“设计之城”最终架构，就很好地阐释了什么才是好的架构，因为该架构图如此地简单，既能清晰地表达设计者意图，又能很好地保证架构的一致性。同时，该图又突出体现了整个系统的核心功能，并通过引入管道-过滤器模式，建立了一个利于扩展、结构清晰的音频架构。
企业应用架构
第3章对伸缩性架构的介绍，以Darkstar开源项目的架构开发为例，较为全面地剖析了整个系统的架构过程。作者特别谈到了该项目支持游戏开发的特征，从而识别出可伸缩性以及并发处理对整个系统的重要性。这就好像是质量属性驱动，或风险驱动，先从最紧要、最核心的部分开始架构的分析，学会取舍，才能更好地遵循帕累托原则，将好钢用到刀刃上。
作者对服务的分解代表了整个架构最重要的设计决策，每个服务承担了不同的职责，既保证了关注点分离，又能因为服务的独立性与自治性，保障系统的可伸缩性。例如通信服务中提供的会话服务（Session Service）与通道服务（Channel Service），就能够因为分离而降低通信机制的复杂性。这很好地体现了架构师的抽象能力，这种抽象既能简化模型，又能隐藏实现，保证系统的可移植与可伸缩。文章写到：
既然所有通信都必须通过Darkstar会话或通道的抽象层，而这些抽象层又不暴露客户端与服务器通信的真实端点，那么在实体通信和通信起止端的实际位置之间就存在着一个抽象层。
文中还提到了“元服务”的概念，我以为这是该架构设计的点睛之笔。
这些元服务是网络层面的服务，对于游戏或虚拟世界的程序员是不可见的，但是它们对Darkstar栈中的服务是相互可见的。
由于元服务对于游戏或虚拟世界的程序员是不可见的，所以它们在任何时刻都可以改变，不会影响到游戏逻辑的正确性。
第4章《记忆留存》的作者Michael Nyard是获得Jolt大奖的《Release It!》一书的作者，长期战斗在一线扮演救火队员的角色，架构实证经验非常丰富。而本章在整本书中，也是工程实证主义表现得最为浓烈的一章。
Michael完整地介绍了Creation Center项目的架构过程。作者通过明确事实，发现重要问题，然后识别关注点的方式来剖析架构，理解需求到功能实现的映射。作者的讲述都是经验之谈，因而总是显得言之有物。例如在讲解架构模块中的渲染管道时，提出了一种“快速失败”模式，遵循“快速失败、大声失败”的设计哲学。之所以运用这一原则，是因为系统的核心功能是生产照片。这样的生产过程不允许因为软件的原因而导致生产线停下来。这就决定了渲染管道的设计必须在最早的过程中进行验证。
整章内容让我唯一感到恼怒的就是篇幅太短，许多步骤、技巧以及设计思想都是点到即止，终究有些隔靴搔痒的感觉。作者自己写道：
我本可以花更多的时间和篇幅来描述每个类、每次迭代或每个设计决定，就像初为人父的人描述宝宝的每次打嗝和摇晃一样。
我私心更希望Michael Nyard能做到这一点，可惜，这个说明读起来更像是偷懒的借口。
我很喜欢第5章《面向资源的架构：在Web中》。抛开Roy Fielding具有卓越远见以及超凡创造性的那篇博士论文不谈，就REST的讲解而言，本章很好地呈露了REST架构风格的原貌。
其实，将REST架构风格引入到企业应用开发中，并非本篇作者的独特见解，譬如说《Rest in Practice》一书的作者Jim Webber等人就是这一观点的坚决拥护者。如果对比本章与《REST in Practice》一书，感觉本章更像是《REST in Practice》的浓缩精华版，虽然作者完全不同。短短的篇幅，不仅给读者深入剖析了面向资源架构的本质特征，还对比了传统的Web服务，阐释了Web的性质，算是理清了REST的历史渊源，基本思想。这个基本思想就是“关注点分离”，REST就是将Web中的人机交互看做是人们感兴趣的资源、操作这些资源的动作以及选择收发这些资源的方式，从而得到名词、动词和表示形式三个重要概念。如文中所说：“REST方式的基本工作原理是分离关注逻辑命名资源、操作资源的方式，以及选择的表示资源的方式”。
当然，如果从Richardson提出的成熟度模型来讲，本章并未过多提及第三级服务的特征，即“Web感知的服务级别，支持超媒体作为应用状态的引擎的观念。”因为就Fielding博士的本意而言，REST是要将超媒体作为应用状态的引擎（Hypermedia As The Engine Of Application State，HATEOAS）。这或许是因为篇幅所限的原因吧。坦白说，这其实也是本书最大的硬伤。因为荟萃了如此众多的优秀架构师，势必不可能给出太多的空间让作者自由发挥。容量的限制决定了整本书的每一章节都是欲言又止的感觉。似乎讲解通透了，读起来又还不够明白。必须要再三研读，方才能明白字里行间的真意。
终端用户应用架构
第12章介绍的Akonadi框架从最初的层划分草案到最后“从里向外、而非自底向上”架构的演进，可谓深得我心。虽然架构策略以及系统背景并不相同，但就我这几年的架构经验来讲，我确实越来越重视内核模式在关注点分离中发挥的作用。许多系统的架构确乎都可以从纵向与横向进行分解，从而获得系统的应用逻辑架构与业务逻辑架构；然而从内核的观点来看，则可以理解为系统多个核心功能的交集，是整个系统的共同品质。它并不一定处于架构的最底层，如基础设施层所包含的内容；也不一定是公共的体现横切关注点的切面（aspect），而是系统最不可缺失的处于核心地位的高内聚职责。
语言与架构
第13章是Bertrand Meyer的大作，提供了很好的例子对比了函数式语言与面向对象语言的优缺点。其实本章的主要观点到如今已经没有太多人会反对。近几年函数式语言的迅猛发展，以及多语言开发的趋势已经说明了二者之间的互补性。本章最有价值的还是Meyer对函数式的推导与优势评价，以及包括对面向对象最基本要素如继承、多态、代理的剖析，这些内容对今时今日掌握面向对象设计技能，理解函数式编程本质思想，仍有非常大的参考价值。
阅读建议
在我这样杂乱的介绍下，本书听起来好像是一盘大杂烩。事实上它确实如此。因为全书涵盖的内容太多太广，以至于让人产生目不暇接之感。尤其对于术有专攻的开发人员来讲，要彻底吃透本书讲解的内容，无疑是一项艰巨的挑战。
然而，如果从架构师所必须具备的技能来看，本书的内容其实并没有超出架构的范畴，因为架构师必须要见识广博，才能针对不同的需求场景，面对不同的实现技术，选出最适合当前场景的恰如其分的架构方案。当然，在阅读时，千万不要在太多的技术细节中迷失自己，关键还是要把握美丽架构的基本原则。而这正是本书的主线，使得本书能够在散乱的主题中，还能做到“形散而神不散”。
《架构之美》评注版摘录
以下内容摘录自我的《架构之美》评注版中的评注：
1
架构是一种trade-off，或者说架构师的职责就是做出设计权衡与决策。在架构设计的早期，我喜欢引入名为Value Sliders的活动，如下图所示：
这一活动主要用于帮助团队进行项目因素或质量因素的权衡。通常情况下，应该是架构师、项目经理及客户一起参与讨论。
这幅图的左侧low代表“可以商量”，右侧high代表“不能商量”。在这两者之间可以用即时贴代表该因素是否可以协调和商量。纵向地看，在一条纵线上只能存在一个即时贴，从而制约着各个因素必须分出不同的优先级，从而做出合理权衡。
2
架构当然有诸多定义，但从某个视角来讲，我们可以认为架构是一种知识的分享，是Communication，每个团队成员都必须充分理解整个系统的架构。而在进行架构设计时，架构师不应该闭门造车，奢求通过自己掌握的知识与技能独立完成系统的架构，而应该成为团队架构活动的facilitator，带领和引导整个团队成员一起参与架构活动，在保障满足合理的架构原则前提下，促进各个成员对整个系统的认识，形成知识分享。
3
DarkStar对服务的层次划分与关注点分离设计原则，值得我们借鉴。我目前正在研发的产品运用了Micro Service模式，而在对服务进行设计时，也借鉴了这里的分层思想。当然，在设计服务时，还要有效地识别出跨服务的公共模块。此时，可以运用Kernel模式，将核心功能视为Kernel模块，而将公开在外的服务视为外部服务。
4
通过Session Service保证进入会话的task message的有序性，使得Task Service的实现可以不用考虑任务处理的并发性，而是利用Session Service的排队机制来约束，使得Task Service的开发变得简单。
Session Service的这种方式让我想起AKKA中的Actor模式。每个Actor都是自治的，并且都维护了能够保证消息顺序的MailBox，这就使得Actor之间的通信变得简单，开发者也不用去考虑消息的并发执行，也避免了传统Shared Memory方式因为引入锁带来的死锁。若要了解AKKA更多知识，可以访问其官方网站：http://akka.io。
