在传统企业应用开发中，项目往往采用"烟囱式"开发模式，数据处理，业务逻辑以及界面操作糅杂在一起，快速推出一个可用版本，这本无可厚非。
但是随着企业应用的发展以及移动互联网的推进，你会发现你的系统无法轻易对接其他厂家系统，也无法快速开发其他平台应用。面对这样的问题，我们不得不考虑架构的变更。而这一切其实都是可预见的或者说是可以提早规划的。
传统架构的问题
传统企业开发架构面对变化总是有诸多的不足：
1.许多模块都要重复造轮子
2.模块间的耦合过深
3.出现问题难以追溯
4.可测试性较差
5.系统间数据和服务无法共享
这样随着项目负责程度的增加必然会导致项目越来越冗余，越来越难以维护。
架构划分
而在我看来，企业软件的开发应该分成服务和终端这两块。
桌面应用，web程序，以及ios,android程序都可视为终端，作为终端我的任务就是展示数据，发起命令/请求，而并不关心其中有多少的业务逻辑和数据处理，我要的只是数据。
而作为服务，我不关心你界面怎么布局，我需要的只是响应你的请求给你数据就行了。
这样的一种架构我觉得能让前台和后台分开协同工作(谁说桌面程序就不能分前后台了)，并且由于统一的业务逻辑可适用于多个终端。
可扩展性
面向服务是一个解耦的过程，松耦合降低了服务之间的依赖。在大项目中为了保证大并发和高可用性，我们通常会将服务组组成一个集群或者将服务拆分为多个部分分开部署。
采用集群部署的模式，通过负载均衡的保持服务的可用性以及每一台服务器的性能(图示为简单架构图，也有采用主从机模式以及分布式数据库模式)
采用服务拆分， 将服务拆分到多个服务器从而达到“分布式”的效果。对于web应用图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的甚至多个图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力。
缓存模式
使用数据缓存在软件工程中是一个非常有意义的策略，不仅仅可以减少数据库负载，而且当数据缓存在内存中，能大大提高了的读取速度。
你可以在你的服务中加入内存缓存也可以将你的数据放到3方的高性能缓存中(memcached,radis等)。
而作为缓存你必须关注的几个方面：
1.这个数据缓存的Key是什么
2.这个数据缓存生命周期有多长
3.如何在外部服务中访问你的缓存
4.缓存数据的落地策略
5.分布式缓存的主从备份
等等，具体的缓存策略需要你结合项目考虑，个人比较推荐memcached，够用就行。
wcf,wcf restful,webservice,webapi?
对于.NET系中这些技术何时使用的问题，上述技术都能做到解耦资源与服务，而采用哪种技术需要视乎你的应用场景。
个人理解而言，对于企业内网应用来说我倾向于使用wcf tcp模式，效率高并且支持双工通信。
而需要对接web和移动应用的时候优先推荐webapi，标准化http协议。之前也用过wcf rest来做手机应用，体验过web api之后感觉wcf还是太重了，webapi得心应手啊。
总结
烟囱式的开发架构我觉得在开发项目原型或者小型项目时可以采用，但凡有可能涉及到web应用和手机应用或者有大并发可能的时候，你得该思考下整体项目的开发架构了。
以上为个人对自己项目的一些经验总结，理解不太深刻的地方欢迎大家指出。