架构是浪费空间的艺术。需要架构师经过缜密的谋划，精心的布置，才能创造出美的艺术。通过阅读本章中对两个“软件城市”的描述，加深了对架构重要性的认识，了解了一些如何构建出美的构架的方法。
经验是最好的老师。当然要善于从别人的经验中汲取经验教训，从别人的错误和成功中汲取教训，可以避免弯路，获取捷径。两个规模相似的系统，都是基于Linux系统的C++语言，并由有经验的程序员兼架构师所编写，然因种种原因，导致了大相径庭的结果。从该现象中汲取经验教训，避免错误。
诸如“混乱大都市”这样的系统，由于起初没有一个清晰的构架，让构建该系统的工作人员感到无比吃力，要知道最难的事情莫过于读别人的代码。没有清晰的进入该系统的路径，也就说明每行程序，每个方法，每个组件都是混乱的堆垒在一起的，没有一致性，不存在所谓的架构，风格；并没有一个清晰的构架，导致程序员无法自脑海中构建出该系统的全图，当将那些构建成功的支路拼接在一起时，更加展示出它的混乱不堪，使用与后期维护都无比艰难。
总结经验教训，出现“混乱大都市”现象的原因是，没有清晰的构建，没有清晰的设计，没有清晰的分层，没有确定的需求分析，每一个设计师各自为营，导致最终的“拼图”无法耦合，于是开始了“混乱大都市”的城市规划灾难。
与此相反，“设计之城”的构建就取得了极大的成功。在一开始，就有清晰定义的目标，这将是一个通用的代码集，可适用于多种产品配置。在设计的早期就已经确定了系统的构架及核心线程模型，并额外设计了“音频通道”等。随着时间的推移，“设计之城”小城初成。
整个系统具有一致性，各个层次都是在整个设计之下写出的，即使在最底层，代码也是一致的。清晰的软件设计减少了重复，熟悉的设计模式、接口惯例到处使用。且架构可以继续增长，甚至改变，使架构不是一成不变的，再有所需要时就可以改变它，这是“混乱大都市”所不敢想象的。
“设计之城”之所以成功，与设计之前就构建了清晰的构架是密不可分的。当真正理解了问题并明白其所需时，再确定其构架，延迟设计决定，直到你必须做出这些决定为止，不要在你不知道需求的时候就做出架构决定，不要猜测。其次，必须保持架构品质，确保系统中从未假如不正确的，不适合的变更，开发者们拥有设计，必须对设计负责。要注重实效。关于代码集的重要决定即所有的代码都要进行单元测试，可避免在修改过程中破坏其他东西，单元测试能够让我们改变设计，所以设计时应考虑代码的可测性。
从两个系统的失败与成功中，可以总结到经验，最突出的差异就在于架构的清晰程度，在设计之初就应该有一个清晰的架构，才能进行后期的代码设计工作。