最近读完<clean architecture>(by Robert C.Martin, 即uncle Bob),和笔者日常所见所思有些共鸣，打算写几段文字，少量是介绍Bob大叔的新书，更多的是记录自己的一些想法，算是借别人的酒浇自己心中的块垒。这说明，这个系列的文字并不打算介绍这本书，即便是引述的内容都未必是Bob大叔想表达的原意(语境改变引起)，而更可能是我故意的曲解。
Bob大叔是敏捷软件开发宣言(2001)的17位签署者之一。今天想到这个事实，感觉似可以和独立宣言的签署者类比，何其奇怪而自然的联想。敏捷的技术实践中软件设计可能是最难落地的。敏捷和<极限编程>都在强调自己是基于价值观的方法。实际上一定有两个问题，其一: 价值观的理解不可能一致，进而引起good words问题，即如果敏捷成为一种主流的开发方法，它所描述的价值观成为所谓good words后，这些词的所指和能指一定发生重大的变化(想想我们今天怎么使用”和谐“这个词? ); 其二: 敏捷价值观本质是一种精英价值观。现实是今天参与软件开发的人，大部分并不是精英，大部分公司也不能招来那么多精英。怎么让软件设计方法使日常的开发获益一直是个问题。
架构的产生，一种看法是它应该是生长出来的，原初应该无知，发生变化,架构应该随着变化生长，类似<反脆弱>一书中所描述的观点;一种看法是，架构是蓝图，应该提前设计出来。实际中肯定会有一个折中，根本原因是我们不可能真的对某个领域无知，太阳之下无新事，总有可以类比成样的东西。一类有广泛市场和大量开发者的产品，往往还会有现成的框架、专用工具等以利开发和提升效率。这个折中的度的选择上，千万不要假装看不见。对于会长期演进的产品，千万不要假装不知道它后来会有各种可以预见和难以想象的新需求，假装看不到长期利益的存在，灰犀牛就在那，谁都不想谈的结果是大家一起完蛋。特别是对于开发者，这么做是愚蠢的，除非你打算写完这个模块就离职(但仍有悖你的职业道德)。架构师对软件的长期利益即它的灵活性(变更的代价)应该负有首要的义务。一般而言出现的问题往往是缺乏设计而非过度设计，更不要借敏捷之名而行缺乏设计之实。
好吧，我的基本看法是，架构师要给出系统拆解的标准和组合的方式，要促使系统上下游达成-致，要分清功能和约束(特别是在处理性能方面)，最重要的是要使这一切具有真实的可行性。不要寄希望于价值观产生直接的效果(价值观很重要，但不够具体)，不要相信架构能在代码中自行健康的生长，一言以蔽之，要做适当的约束和控制。
计划中的话题包括
(一)软件的核心价值:长期演进
(二)编程范式的变化:约束能力
(三)组件设计原则
(四)原则间的矛盾: SIP vs ISP
(五)架构关心什么
(六)划分边界
(七)抽象和接口
(八)核心域和分层
(九)敏捷价值观和现实的碰撞
(十)架构师的职责
一到七节，基本按<clean architecture>- -书的脉络走，最后三节和此书关系不大，但和我理解的架构师的职责有很大的关系。
