本文是继 AgileEAS.NET应用开发平台介绍及 AgileEAS.NET之敏捷并行开发方法所做的架构补充，用于阐释AgileEAS.NET平台的架构设计思路。

      说起了系统架构，我也无法给出系统架构的确切定义，我的理解也许也只是基于自己经验的一个片断，我是学习园林专业身的，学习过园林建筑学，也许对软件框架最早的理解来源于对建筑的理解，我们知道，一个好的建筑必须解决建筑及其附属物的荷载及其美观和居住的舒适性，而这个必须通过其建筑的骨架--承重体系来支撑，建筑最先进行的其他承重休息的浇筑。

软件之系统架构有如建筑的骨架，不同规模、不同地域、不同应用的建筑会使用不同的承重结构。软件系统架构的设计如同对建筑的框架设计一样，对于不同的应用应该应用与之相匹配不同的架构，也就是说，客户的应用决定着项目的架构及到技术选项。

      AgileEAS.NET平台所提出的系统架构适应于中小规律的管理信息系统。

      在 AgileEAS.NET应用开发平台介绍中我画出了AgileEAS.NET的基本架构图，本文我从系统的横向扩展和纵向伸缩两个方面来讨论。

横向扩展：

      AgileEAS.NET平台是基于“并行开发”这种思想支持的应用平台，我们在在DotNET中用平台+插件实现了这么一种理念，其核心的机制既用插件横行扩展平台。

      采用这种思路构建和扩展业务系统，需要一个统一的机制允许业务插件注册到平台，基于这种思路，各个业务模块，都变成了可以自由组装、拆卸的插件。

      插件运行容器是一组能够实现插件业务调用的一组应用程序，可以是基于WinFrom的桌面应用程序、也可以是基于Web的网站应用，运行容器调用插件并由插件横向扩展运行容器的功能，这样一来，应用系统的开发就转成为对运行容器的功能扩展，也就是项目的重点转移于开发模块插件这个焦点。

      业务插件的开发者可以选择利用AgileEAS.NET所提供的快速开发技术实现，即依赖于平台所提供的基础组件，也可以选用开发者自己的技术去实现模块插件，这将涉及到系统的纵向伸缩的问题。 

      不要是说搞软件的技术人员，就是某些客户机构人员，也跟你嚷嚷的要求软件弄成三层结构才行，我想这个三并不指特定的三层吧，应该是泛指三或者多层结构吧。

      目前，大家所指的三层结构应该是对系统进行的所谓界面(UI)、业务逻辑(BI)、数据访问(DA)三层吧，多层也是对这三层进行了详细的分解的结果，业界经验证明，这确实是解决系统复杂性的一种主流模式。但并不是说应用了三层架构就一定能解决系统的复杂性，他不是万能的。他提供给我们一种解决复杂问题的思路，那就是根据应用的复杂程度合理的去分层。

      对于这种分层设计，我建议根据项目的实际情况合理的选择合理的分层设计，如果对于很小的项目选择复杂的分层设计，就会演变成为分层而分层的一种漩涡。

      AgileEAS.NET支持不同层级的开发，对于很简单的项目，你可以选择把界面、业务、数据访问全部放在模块模块UI实现；对于较复杂的项目，可以选择使用模块UI+数据访问层，把业务逻辑并入UI实现，更为复杂的项目可以把界面、业务、数据三部分严格分解甚至可以把这三层中的任务一层再分解，比方，数据访问层可以分解为数据访问接口层、数据访问实现层等,AgileEAS.NET提供一个基于消息的分布式通信服务，应用系统可选的基于它实现分布式应用。

      总之，系统的架构取决于客户的应用、技术力量等诸多方面，优秀的架构在于系统扩展、伸缩性以及系统的抽像程度之间寻找一种平衡。

本文转自 agilelab 51CTO博客，原文链接:http://blog.51cto.com/agilelab/561885