整洁架构（1）简介
最近开始做一些软体架构的工作，觉得自己对于软体架构的知识比较匮乏。同事推荐了这本"Clean Architecture ---A Craftsmans Guide To Software Structure And Design". 评价非常高，内容很经典，我就系统的学了学，原著是英文的，市面上并没有中文版。我就边度英文原著，边做了一些中文的读书笔记。
事实上，架构就是设计，他们之间没有什么区别。就像房子的建筑师，要设计房子的尺寸布局和形状等等。
架构的目标是什么？
一个乌托邦式的描述:
软体架构的目标就是最小化为了构建和维护软体系统所需的人力资源
列举一些事实:
一个市场主导的软体产品，所产生的代码量逐年上升
当然对于程序员来说，他们每天都很努力，然而生产率也确实在下降。
如果你比较了图5和图2，你就会发现，开始的时候几百美元就可以买来许多功能代码，而到了最后，2百万美元基本什么都没有买到。任何一个CFO看到这两幅图，都会知道，立即要做些什么来组织这场灾难！
2600年前的龟兔赛跑故事，阐述了一个道理：
通俗一点讲就是，不图快，但求稳！
Jason Gorman做了一个有趣的实验, 他编写了一个整数变罗马数字的简单程序。然后他每天只花费30分钟来做这个实验。第1,3,5天，他采用了TDD(test-driven), 第2,4,6天他选择不采用任何策略的写代码。其中的效率图表如下图：
所以结论就是：
正因为这样，我们需要开始认真的谈论软体架构的质量了。
任何软体系统，都提供两种不同的价值：Behavior和Structure.
软体开发者应该负责确保两个价值都保持很高。不幸的是，他们总是注重一个而忽略另一个，甚至两个都忽略了。这样的话，软体系统就没有了相应的价值。
Behavior
这是软体第一个价值。程序员被雇佣来编写机器的行为方式来挣钱，并满足顾客需求。我们帮助stakeholders来开发功能规范或者需求文件。然后通过写代码来满足客户的需求。
当机器违背了这些需求，程序员就需要通过debug来修复问题。
许多程序员觉得这就是他们所有的工作。他们相信他们的工作就是让机器来实现需求并修复bugs。很悲哀，他们错了。
架构Architecture
软体必须"软". 也就意味著，软体应该很容易被改变。当客户改变了他们的想法，这些改变应该可以简单和容易去实现。
新的变化的需求越来越难去适应已有的构架，因为系统的形状越来越难匹配需求的形状。
问题当然就出在于构架。一个构架如果越喜欢一种形状，那么越多的 新feature就越难添加进来。因此构架应该是无关形状的。
中国老子有句古话：大象无形。表示宏大的方正（形象）一般看不出棱角。也应该就是这个意思吧。
更重要的价值
到底是功能更重要还是构架更重要。不同的人可能说辞不同。
但是事实是，如果你给我一段程序，运行得很好，但当需求改变时，他不可能被修改。那么这段程序就是没有用的。
对于软体架构师的挑战是更加艰巨的。架构师创建一个架构，允许features and functions可以被容易的开发，修改和扩展。
推荐阅读：
