总结：我喜欢的软件体系结构——分层、模块化与OSGi

软件体系解构是一个比较抽象的概念，按我的理解，可以将其比作一个书架。书架的产生过程大概如下：（1）没有太多的书，想怎么摆都行，不至于太乱、难以分类和查找；（2）越来越多的书籍，你需要考虑是横着排列，还是竖着排列呢？横着排列的话，很容易倒不说，而且很难找到自己想要的且书籍；竖着排列的话，容易找到自己需要的书籍，但是太占地方，而且如果把书竖着摆条长龙的话，拿出几本书后，需要重新整理；（3）因此，我们考虑使用一个架子，这个架子分成几层，每层竖放一排书；（4）在书更多的情况下，需要对每一层加上一个格子，并且为每一本书和每一个格子打上标签；（5）随着时间推移，书架就组成一个图书馆了。软件体系结构对于软件系统构建的作用类似于书架对图书馆的作用了，同时对它的探索也类似人类对图书馆架构优化的探索。这段比喻只是让人初步理解一下它的概念，对其理论在此不作讨论，如果有兴趣的话，可以直接看点书。本文接下来将讨论一下笔者喜欢的一个体系结构。

一个软件系统向用户提供了若干功能，用户使用的每一个功能，我认为，是一种软件纵向代码执行的过程。换句话说，即软件系统是由横向的功能组成，每一个功能的应用是一种纵向代码执行的过程。举个例子，当用户想查询某个股票的行情的话，它会输入一些信息到软件系统，软件系统获取用户输入、执行校验、查询业务逻辑处理、路由到网络某个终端、运行查询服务、执行数据库访问、返回服务结果、经过业务逻辑处理、呈现到用户界面，这种行为从软件系统代码的执行角度来看，可以说是纵向的行为。这种纵向行为中的每一个活动都与前后活动相互关联，在代码中也呈现出直接的依赖。可以这么说，经典的分层体系结构是对横向软件功能的纵向代码的分类，从而划分层次。最初的分层结构是3层体系结构，即根据软件系统各个功能的纵向行为，划分为业务层、逻辑层和数据访问层，随着软件系统日益复杂，开发人员为软件系统抽象了更多类别（层次）的活动，出现了另一7层经典的分层结构。

单从软件系统本身而言，其复杂性由横向（系统功能）复杂度和纵向（涉及的业务逻辑和技术）复杂度组成。分层结构的出现，容易让人只是关注软件的纵向复杂度，对于越复杂的软件系统，我们需要划分成更多的层次。然而越多的层次，意味着更多、更复杂的层间依赖，也使开发、调试变得越来越复杂，在我看来，有点违背了“KISS”原则。当然，有人会说，这已经是最优方案了，也就是面对复杂系统，无奈的最优方案。幸运的是，人们已经发现了这些问题，并衍生了一系列的经典的开发框架，如MVC/MVP/MVVM，IOC，AOP，ORM。这些框架的出现大大降低了复杂系统的复杂性。不过，框架的大量应用，降低系统复杂性的同时，也意味着我们首先需要再付出相应的代价来使用这些框架，引入了更多的编程规则，从另一角度来看，也相应的增加了复杂性。举个例子，一个对象直接依赖另一个对象，肯定要比一个对象通过IOC容器依赖另一个对象来的简单，因为后者不直观而且还应用了新的框架。因此，这种只关注软件纵向活动的分层体系结构是有很大缺陷的。（PS：对于IOC框架，对于我来说，则是能不用最好不用。我想它对我们最大吸引力的地方，就是我们在开发项目的过程中，可以根据需求变化，而直接修改配置文件或者更改少量的代码，避免陷入用户无休止的变更中。当然，IOC的应用也提高了代码的可测性。但是，利用IOC真正有价值的部分只有一点点，因此，我只是觉得按需即可。我以前喜欢追求有艺术的代码，什么是有艺术的代码呢？那就是要有技术含量，殊不知，简单就是艺术！）。

因此，我想换一个角度，从横向复杂度入手，对系统进行模块化切割，从而使得每一个模块尽量的独立且简单。一个纵向复杂度很低的模块，我们甚至什么框架都不需要用到，而且我们可以根据模块的纵向复杂度对每一个模块划分层次。不过，引入模块化进行系统架构，我们不得不解决：（1）如何组装模块？（2）如何解决模块的依赖关系？（3）如何确保模块的独立性，从而降低模块间相互影响？（4）如何开发、调试和部署模块？

OSGi规范的提出，为我们解决了模块化应用的所有问题。对于（1），在OSGi中，每一个模块被称为Bundle，即服务包，由Bundle清单文件、代码文件和资源文件组成。OSGi框架可以从一个文件、文件夹、URL中加载模块。OSGi完整定义了模块化应用系统的单元。对于（2），OSGi提供了2种方法来解决模块依赖：1）是在模块编码的时候，一个模块重用了另一个模块的功能，它通过模块清单的Import、Export、DynamicImport和Require配置来解决；或者是一个模块继承或在方法、字段的定义上使用了另一个模块的类，它将通过USE指令来定义。2）模块使用了另一个模块提供的服务，这种依赖只能在模块运行的过程中才能体现出来。对于（3），OSGi规范严格定义了框架类加载机制，由Java的ClassLoader代理网络，确保OSGi能够为每一个模块创建独立的类型空间，避免模块间类型的相互影响。对于（4），在开发和部署环节，IDE和OSGi规范已经提供简单、完美的支持，而对于本地调试和远程调试，IDE和运行时虚拟机也都完美支持。

总结：我喜欢的软件体系结构就是模块化（插件化） + SOA！通过模块化思路切割复杂应用系统，通过可管理的服务来解决模块依赖，尽量减少框架的使用和模块的层次，从而使得一切变得简单，达到“简单就是艺术”。