6.1 分解
尽管标准多种多样，但大型系统开发的主要任务是降低系统的复杂性。为了降低复杂性，除了分成几部分之外什么也没有发明。
有时，为了简单起见，这被称为“分而治之”原则，但是，从软件架构师的角度来看，我们谈论的是层次分解。
一个复杂的系统必须由少量较简单的子系统构建而成，每个子系统又由较小的部分构建，依此类推，直到最小的部分足够简单，可以直接理解和创建。
好消息是这个解决方案不仅是唯一已知的，而且是通用的。除了降低复杂性之外，它还通过复制关键部分同时提供系统灵活性、良好的可扩展性和增强的弹性。
因此，当谈到构建程序的体系结构、创建其结构时，这意味着将程序分解为子系统、服务、层、子例程和功能模块，并组织它们之间以及与外部世界的交互。
这里最有价值的是：子系统越独立，在特定时间点专注于每个子系统的开发而不用担心所有其他部分就越安全。
6.2 模块化架构的好处
使用层次分解原则可以让你摆脱代码中数千个类的混乱。还记得你的代码被分成包（package）和子包吗？这是层次分解的一种表达方式。
你的程序从一堆类变成了一组库和模块，它们根据明确定义的简单规则相互交互。反过来，这使您能够控制其复杂性，并让您有机会获得通常与良好架构概念相关的所有好处。
以下是最基本的：
- 可扩展性——通过添加新模块扩展系统并提高其性能的能力。
- 可维护性——改变一个模块不需要改变其他模块。
- 模块的可交换性（Swappability）——模块可以很容易地被另一个替换。
- 单元测试——一个单元可以与所有其他单元分离并进行测试/修复。
- 可重用性——模块可以在其他程序和其他环境中重用。
- 维护——一个被分成模块的程序更容易理解和维护。
可以说，将一个复杂的问题分解成简单的碎片是所有设计技术的目标。在大多数情况下，术语“架构”只是指这种划分的结果加上“一些一旦采用就难以更改的设计决策”（Martin Fowler“企业软件应用程序架构”）。
因此，大多数定义以一种或另一种形式归结为以下内容：
“架构确定了系统的主要组件以及它们如何交互。它也是对此类决策的选择，这些决策被解释为基本的并且在未来不会发生变化。”
“架构是一个系统的组织，体现在它的组件中，它们之间的关系以及它们与环境的关系。系统是一组组合起来执行特定功能的组件。”
因此，好的架构首先是模块化/块式架构。要获得良好的架构，您需要知道如何正确分解系统。这意味着有必要了解哪种分解被认为是“正确的”，以及如何最好地进行分解。