以架构为中心

架构，根据OMG在MDA中的定义，就是指系统由哪些组件组成，以及这些组件之间的相互关系。关注这些问题的人，称为架构师。业务系统由哪些子系统组成，这些子系统之间的相互关系如何，就是业务架构。在技术层面上，采用BS的三层架构，这是指技术架构。

RUP是强调架构的。在早期的RUP文档中，指出RUP的特点是：用例驱动、以架构为中心、迭代增量式开发。很正确。谁说不是呢？换句话说，就是：业务需求驱动、关注设计的优秀性、早发布常发布。以架构为中心的理由是，好的架构具有弹性，可以容纳将来可能的变化。

Java是强调架构的。Java提供了极为灵活的架构，所以为后来的发展提供了巨大的可能性。可以添加新的特征，而不用伤筋动骨。

在考虑类的设计、类之间的协作 关系时，也是在设计架构。好的类设计为将来的特征添加提供了可能性。以前面文章中提到的彩色UML设计为例：

将来可能添加的特征包括：
列出某个店的所有员工
列出所有的店和店主
列出某个员工的任职经历
列出某个店的历任店主
列出曾经担任过店主的所有员工
......

彩色UML设计保留了完备的信息，在今后系统需要添加新的特征时，不需要改设计（架构）。这就是弹性。

Matin Fowler有点反对架构的意思。 YANGNI (You are not gonna need it) 。甚至说做过架构师的人他一律不招。如果我没有错误理解他的意思，那他基本上是错了。我们可以重构，架构可以演进，但我们追求的是一次做对。总是惦记着错了可以推倒重来是不好的。就像小学生，用橡皮上瘾。就像下棋，老想着悔棋。应该像中国书法和绘画一样，追求一笔下去，就不能改，也不用改了。就这么点追求，不过分吧？

人无远虑，必有近忧。完全不为明天考虑，不为将来可能的变化考虑，这是什么样的人啊？