记得几年前不管开发什么系统，都会引入log4net进行系统的日志记录，当时只沉迷于这个组件带来的超强日志功能。不过很快我们就尝到了恶果，经常在日志无输出时，在试了google出来不知道原因的解决方法失败后，只能将log4net源码全部attach上，慢慢的一行一行追踪这个庞大的类库来找出原因。
有时我们甚至不得不进行日志的日志设计，在日志失败时，使用我们自己的，最直接的，最简单的，最少出错的方式来记录日志的出错信息。
而在我们头痛时，那个看似可应付无穷变化的组件却几乎一次也没有给我们带来惊喜。
日志永远在Warn级别输出，日志永远存在系统的D盘根目录/系统名称下，异常和警告邮件永远都会发向开发组的一个共用mail，日志的格式更是从来没有变过，谁没事天天会去琢磨日志是不是该增加一个什么记录？就算要增加，那也几乎要修改所有调用日志的地方，幻想只通过修改那个格式配置文件就行？
当我们最终想要换掉这个日志组件，重新换上一个不超过100行的自己写的日志类时，这时才发现日志的变化点在哪里？原来日志模块可能的变化是抽掉整个日志模块，而不是整天考虑是日志在C盘还是D盘，是记录Error还是Warn，是要输出日志到Console还是资料库？
为什么会这样，为什么该变的没有变，不该变的又频繁在变？
现在企业开发有很多平台和框架，像.net的Enterprise Libaray和java的SSH等。
无论是何种方式，何种平台，都无法逃避系统开发的一般问题域的处理。例如如何进行数据访问，如何输出日志，如何处理错误，如何读取系统配置。。。
在面对这些问题时，人们更多的时候是在寻找一个框架，即使这个框架大到你只想要一个轮子而不得不接收它的整个车子，你依然不会怀疑为什么这样做，当你终于被这个车子的其它零部件影响到你这个小小的轮子行驶，而不得不到处google爬文或分析源码，在弄得焦头烂额，筋疲力尽之时，你心里又会不会发出：这个。。。 能不能简单点的抱怨？
系统设计中，变化是一条军规，变化成就了今天的各种框架，类库和模式。然而当我们洋洋自得于我们的系统应对变化的能力的同时。却没有反思变化会带给我们的影响，我们不得不为一个几百年都不会第二次实现的接口而带来的复杂性买单？
对于一个优秀的系统架构师来说，他除了要为应对变化而施展他的艺术创作才华，很多时候他也必须分清哪些是需要变化的，哪些是可以变化的，哪些是不会变化。
而要认清这些不同的变化，首先就要理解问题域的本质，例如缓存处理，为什么要缓存处理，它有什么用，在系统中处于什么样的地位，和其它模块的接口在哪里？哪些是缓存可变的，哪些是缓存不会变的，当变化时在哪里处理这个变化，对系统的其它模块的影响在哪里？只有认清这些，才会在引入某个模块时做到心中有数，避开它的负面影响。
与到处考虑变化相反的是，很多时候我们却在排斥合理的变化。如经常看到一些询问如何应对表结构修改，如何在增加栏位时不修改系统的讨论。
有人认为是需求人员或系统分析师没有做好，要是做好了，就不会栏位变化了。这可能是没有遇到一些比较复杂的系统，我们这边一个财务系统，因为供应商，客户的付款，收货规则每次都在调整，因此基本上每个月系统都会对一些流程，业务实体作修改，想固定不变，那我们的工资都可能算不出来了。
实际上，系统要做到不变是不可能的，因为世界每天都在变，市场也在变，企业的管理者会随着市场的变化而持续检视自己的经营行为，改变流程，优化流程，缩短流程，而作为系统的架构师就是要当流程变化时，最快的修改系统以适应新的变化。
变化反应了一个系统的生命力，只有经常变化，系统才能持续产生价值。相反，僵化，这也不能动，那也不能改的系统最终会很快地淘汰出局。
作为一个系统架构师，当然希望需求分析比较完整，比较准确。但更重要的是了解系统会在何处变化，会怎样变化，会何时变化，这也是经常讲的技术不重要，业务重要的一层意思。
因为如果一点都不了解你系统的业务，就不能在需求信息不完整或不准确时，作出哪些变化，哪些不变的架构，从而在系统真正发生变化时，无力应对。
企业开发中，只有变化才是真正的不变，而抓住那些可以不变，或基本不变的保持稳定。大胆地将一定会变的，很大程度会变的进行最大的变化设计，最终完成系统架构。
从事企业开发将近8年，希望在满十年的时候能够完成自己对企业开发的理解和总结，因此决定开始这个系列，是为序。
