在本书的第二部分重新审视了一下三种基本的编程范式：结构化程序设计、面向对象的程序设计与函数式编程，并提出了一个重要观点：
从1946年图灵为电子计算机写下第一行代码到现在，软件的基本规则一直没有变过。计算机程序的最基本构件始终是顺序（执行）、选择、递归和间接应用（indirection）。编程范式并没有在增加我们的能力，反而限制了某些我们写代码的方式。简单来说，编程范式就是告诉我们不要做什么。
结构化程序设计
1968年Dijkstra提出结构化程序设计思想的时候指出“GOTO语句是有害的”，这之后出现的很多编程语言限制或彻底取消了GOTO语句。结构化程序设计对控制的直接转移进行了限制。
Dijkstra曾经试图将数学中的形式证明方法引入计算机软件领域，从简单的“公理”出发，通过规范的形式逻辑推导，证明计算机程序的正确性。当然我们现在知道他的这个“理想”失败了。至今还没有方法可以“证明”程序的正确性。
但是，程序是“可测试的”。从这一点来说，软件更接近科学而不是数学。“可测试的”对应了科学中的“可证伪的”。正是创建“可证伪的”（可测试的）程序单元的能力使得结构化程序设计到今天依然非常有价值。在架构层次上，功能分解依然是最佳实践之一。
软件架构致力于定义易于测试的模块、组件与服务。
面向对象程序设计
作者首先分析了传统上对OOP的特征的总结：封装、继承和多态，指出这三个特征并不能确切描述OO的特性。在没有OOP以前，C语言就可以实现将数据和函数封装为一个模块，隐藏私有数据的同时对外暴露公开的函数。同样的，在OOP以前，C语言也可以实现继承。当然OOP使得实现继承更方便了。
在没有OOP以前，通过函数指针一样可以实现多态。但是OOP使得多态的实现更加安全和方便。使用函数指针时需要遵循一系列人为的约定或惯用法，如果在这方面稍有疏漏就可能产生非常难以跟踪与消除的错误。而OOP提供的多态机制消除了这样的风险。
虽然同样都没有提供全新的特性，只是使原有的编程方法更安全和方便，但是作者显然认为多态比继承更有价值，至少在架构的层面的如此，因为正是多态使我们可以做到“依赖倒置”（Dependency Inversion）：
> OO语言提供了安全而方便的多态机制的事实意味着任何源代码依赖关系——无论在什么地方——都可以被颠倒过来。
在本书后面的很大篇幅都在将“整洁”的软件架构中应该有怎样的组件依赖关系，而要实现理想中的依赖关系，没有“依赖倒置”是不可能做到的。
最后总结，什么是OO？ 对于软件架构来说，OO就是通过使用多态，完全地控制系统中所有源代码依赖关系的能力。
函数式编程
函数式编程的概念可以追溯到二十世纪三十年代Alonzo Church发明的Lambda-算子。但是函数式编程之所以最近又“火”了起来，是因为函数式编程比指令式编程需要多得多的内存和处理能力。这只有在存储器和计算能力非常廉价的今天才有可能实现。
函数式编程限制了我们对变量的使用。纯粹的函数式编程中，变量都是“不可变”的（immutable），实际上等于取消了“变量”。
竞争条件(race conditions)、死锁、并发更新，这些并发程序中常见的难题都是由于可变的变量引起的。函数式编程通过强制immutable，也就消除了这些问题。
纯粹的函数式编程需要无限的内容和处理能力，并且当程序需要与外部设备交互式，几乎不可能避免处理可变状态。这些问题可以通过一些妥协手段。
一个是对“可变性”的隔离。将程序分为不可变状态的组件和可变状态的组件。前者依赖后者，程序状态再保存在“Transactional Memory”中，通过一些不可并发的原子操作进行处理。
另一个是只保存事务、不保存状态，称之为Event Sourcing。当需要查询状态时便重新计算一下所有事务，得出最新状态。这样就把数据的CRUD操作简化成只有“C(reate) R(ead)”操作了。网上关于Event Sourcing的内容很多，这也是DDD (Domain Driven Design)中的重要内容，在此不赘述。