我们怎样拥抱变化
软件系统应对快速变化的终极利器，是以领域模型为核心建立的软件架构。
软件发展的基本特征就是变更，不论是源于需求的变更还是源于技术的变更。
运用领域模型，通过图形化的分析，可以让我们快速掌握真实世界的规律，进而指导软件的设计与开发。领域模型是联系真实世界与软件世界的枢纽，首先通过对真实世界的分析绘制领域模型，然后照着领域模型设计软件，就可以保证真实世界与软件世界的对应关系。
一般来说，领域模型是基于用户业务领域知识的分析，这些领域知识源于用户对软件系统的业务需求，却超越了业务需求。
领域模型，就是我们在逐渐学习和掌握用户的业务领域的过程中，将业务领域中的相关业务规则，以图形化的方式抽象成模型，方便我们日后的学习和交流。
基于领域模型的分析过程是一个科学的分析过程，它有它的一套科学的方法。通过这些方法才能保证我们分析的正确性。两种领域分析方法：原文分析法与领域驱动设计。
原文分析法(Textual Analysis)，是在用例分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。采用原文分析法之前我们首先就应当将业务需求整理成用例模型，为每个用例编写用例说明，之后对用例说明中事件流的文字描述进行原文分析。
领域模型是一种图形化的模型，既然是图形化的，就非常容易交流，为各方面的人员所接受。领域模型脱离技术，纯粹站在业务领域的角度进行探讨与交流。它采用类图的方式在描述业务的问题。
作为一个系统架构师，应当考虑一个足够合理的折中，以最大限度满足各方的需求。
先熟悉整个系统，然后是某个模块，之后是某个功能，再然后是你要修改的某个分支，最后到某段代码。慢慢地，你开始将分析的工作由业务功能向代码实现上细化。不要一行一行地读代码，那样效率很低。一个函数一个函数地去阅读，如果明白了某个函数的作用，甚至可以不用去阅读函数的内容。
快速阅读代码的另一个十分有效的方法就是重构。运用重构的方法去分解系统，以支持你对系统代码的理解，是非常有用的。
领域模型的绘制体现的是你对业务系统相关业务的认知程度，最初可能是肤浅的，甚至还会有错误。但没有关系，它代表了你再一步一步积极地学习。
测试的困境
自动化测试不是银弹，它不能解决测试过程中所有的问题。它不能测试与web容器密切相关的程序，也不能测试与数据库密切相关的代码。因此，我们不能因为追求覆盖率而盲目地编写自动化测试程序。
我们建立自动化测试的目的是：为了在日后的重构过程中不会让这些既有功能出错。
建立自动化测试体系：
起初，我们首先建立起基于QTP的自动化测试，让原有程序都能测试通过，接着开始重构。随着重构工作的逐渐进行，业务程序逐渐与web容器和数据库解耦，可以开始编写基于单元测试框架的自动化测试程序。
系统重构的评价
超大函数的数量就是第一个评价指标，无所不能的大对象也不失为一个客观的评价指标，因此，评价一流系统中大对象的数据，是第二个评价指标，系统代码的复用率，代码依赖度。