你的架构是如何一步步腐化的？

你的架构是如何一步步腐化的？
架构这个词在各种场合不断地以各种面目表现出来。从维基百科的词条看来，我们经常听到的有插件架构（Plugin），以数据库为中心的架构（Database Centric），模型-视图-控制器架构（MVC），面向服务的架构（SOA），三层模型(Three-Tier model)，模型驱动架构（MDA）等等等等。奇妙的是，这些词越大，实际的开发者就越痛苦。

一些基本的准则：

• 为了降低耦合，系统应当以恰当的方式进行分层。目前最经考验的分层是MVC+Service。
• 为了提供基础的访问，一些基本的、平台级别的API应该被引入。用Spring之类的框架来做这件事情。
• 用AOP进行横向切分业务层面共性的操作，例如日志、权限等。
• 为了保证项目正常构建，你还需要数据库、持续集成服务器，以及对应的与环境无关的构建脚本和数据库迁移脚本。

常见的动作往往围绕着重构——将纵向相关的抽取出来，形成一个新的项目；横向相关的抽取出来，形成一个名叫common或者base的项目。

解决方案

0. 采用新技术

1. 重构到物理隔离的组件

解决方案是物理隔离这些组件。就像团队在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord这些库的时候，不用将它们对应的源代码放到工作空间进行编译一样，团队也可以将稳定工作的代码单元整理出来形成对应的库，标记版本然后直接引用二进制文件。

每个模块都有属于自己的代码库，拥有自己的独立的升级和发布周期，甚至有自己的文档。

这一方案看起来很容易理解，但在实际操作过程中则困难重重。团队运转很长一段时间之后，很少有人去关心模块之间的依赖。一旦要拆分出来，去分析几十上百个现存项目之间的依赖相当费劲。最简单的处理办法是，检查代码库的提交记录，例如最近3个月之内某个模块就没有人提交过，那么这个模块基本上就可以拿出来形成二进制依赖了。

一旦团队开始这样去思考，每隔一段时间重新审视代码库，你会发现核心代码库不可能失控，同时也获得了一组设计良好、工作稳定的组件。

2. 将独立的模块放入独立的进程

3. 形成高度松散耦合的平台+应用