我认为设计一个好的系统架构至少要考虑以下几点：
0.限定系统架构应用边界
满足一切应用场景的系统架构就是没有架构，想一开始就设计一个大而全的系统架构是高风险的，因此最好的解决方案就是针对不同的应用场景准备不同的小范围架构，然后通过一定时间的熟悉、沉淀、积累、再思考、重构与组合之后，再慢慢扩展成满足较大应用场景的架构，我现在使用的架构，它最开始就是从仅仅解决OR映射的数据访问层框架开始的，经过十多年的发展，目前已经达到了一个满足一般企业应用业务场景的标准四层体系架构。
1.一切以客户为中心
系统架构的最直接客户就是程序员，如何才让程序员更乐于使用我们设计出来的架构呢，我觉得最根本的方式就是站在程序员的角度来思考，隐藏系统架构真实的复杂度，以最少知识原则，用最简单、最直观的方式将系统架构的功能，呈现给程序员，让他们切实体会到使用架构而带来的便利和实惠。比如对于服务的消费，程序员更希望的消费方式如下：
IService service = ServiceFactory.Create<IService>();
using(service as IDisposable)
{
service.CallSomeMethod;
}
而系统架构要实现这种方式的调用，后台至少要做两个比较复杂的工作，一是通过服务总线查找服务地址及服务描述，并创建服务代理。二是通过对服务实例的依赖注入屏蔽掉未注册的异常，否时当调用服务出错时，永远只会抛出服务通道状态无效异常。
2.变化即增加
改变总是困难的，因为很可能早已物事人非。这就要求我们在设计架构时要尽量考虑到一些可变因素，并通过模块化设计，插件式设计，以增加的方式来解决未来的变化。
比如我们框架中要提供一个通过短信猫来收发短信的服务，那这里面可能存在的变化有以下几个：
一、今后的发送接收方式可能会变化，由短信猫转为短信网关
二、今后接收到的短信处理方式可能会变化，如临时性的捐款确认等等
三、今后发送短信的数量可能会增多，如从每天一千条到每天百万条
对于第一条，我们可以一开始就定义短信设备接口，当转换发送方式时，我们只要增加一个短信设备接口实现，并通过修改配置文件来实现。
对于第二条，我们可以定义短消息到达事件接口，并引入发布订阅模式，当有新的短信处理方式时，我们只要增加一个短消息到达事件的订阅者就可以了。
对于第三条，我们可以在初期引入消息队列，异步发送消息，并同时将服务设计为无状态的，当现有服务不能满足应用需求时，可以通过负载均衡增加物理服务器的方式来解决。
3.高聚合、低耦合
作为技术型人员的程序员总是会被这样或那样的事情所烦恼，如果要完成一个功能模块，他们不得不和太多的其他的非业务人员去沟通，那么效率就会大大降低。我们设计架构的时候也要从这个方面去考虑，希望程序员能在相互之间没有依赖或依赖较少的情况下比较独立的工作。比如我们引入企业服务总线及异步事件机制，减少服务（功能模块）之间的依赖，提供服务、流程的自注册服务，减少开发人员对管理平台、部署人员的依赖等等。
4.全局考虑可互操作性、安全性、可测量性、扩展性
好的系统架构应该能将程序员从一些基本而又复杂的性能、质量、安全需求中解脱出来，让他们更能专注上层的业务需求的实现。
比如我们可以在系统架构中实现服务查找和定位来提升可互操作性，提供单点登录、基于角色的认证来实现整体安全性，提供测量模块通过简单配置方式来实现新增服务的可测量性，提供服务的路由算法来实现负载均衡提高可扩展性等等
5.通过提供基本模块、编码规范、生成工具、示例项目、培训文档实现最大的重用
很多项目中的基本模块都是相通的，我们可以将这些模块包含在框架中以便重用，而好的经验都是可以重复利用的，比如异常处理，我们可以通过编码规范来制定数据层，数据访问层，业务处理层，服务层，UI层的不同层次的处理策略。利用生成工具，可以帮助程序员节省大量的时间来生成很多标准的代码，通过示例项目可以更直观的向程序员展示一般问题的解决方法，以及项目层次的划分、意义和实现，通过培训文档可以帮助程序员提高对一些难点如事务及锁处理、线程并发处理等等的掌握。
