“基本上每个人，在第一次构建一个分布式应用时，多会做出下面十个假设。但是在长期的运作过程中，他们都会被证明是错误的，而且会引发大麻烦和令人痛苦的学习经历”。
1. 网络是可靠的。在面对网络时，它很难称得上是我们所谓的可靠——对于当今的互联网来说，丢失报文、服务器宕机、路由器被黑，等等这些依然是现实存在的。尽管你的网络可能真的是永远不会崩溃，但是你的网络并不是你唯一需要考虑的——所有那些你不能做出保证的网络也要保持处于激活状态。这就是为什么需要你的系统在面临故障的时候是健壮的，同时还需要你去定义系统所需的性能和可扩展性的类型，以使你可以确保你所拥有的基础设施可以处理故障。
2. 响应时间是零。网络不是免费的——它会把时间花到通过网线（以及许多构成互联网的中间设备）传输工具上。在开发过程中，网络的响应时间经常是非常接近于零，如果开发部门与其它部门的网络是物理隔离的，那就更是如此，这在大型的公司中非常常见。事实上，在很多情况下，响应时间会尽其可能的接近与零，这是因为开发者的习惯是为了方便起见，在同一台机器上运行所有的层——应用服务器、浏览器、数据库和其它任何必须的东西。但是不要忘了，特别是在Web应用的情况下，你的客户可能不是在100-或1000-兆的网络上，有些可能仍然是在拨号上网，这取决于客户端的选择。正是应为这个原因，所以要确保作为表示层部分或通信连接的主体部分而被传输的数据量要最小化。
3. 宽带是无限的。与我们想要的正好相反，网络在同一时刻可以发送的信息量具有有限的容量。特别是当企业系统暴露给公众，而某些我们潜在的用户仍然运行在慢速的拨号连接上和饱和的DSL连接上时，我们将具有与LAN同等的带宽的想法是可笑的。这就是为什么又是尽可能多的将人物从线上移除，而采用厚客户端去访问传统的基于HTML的系统的原因。
4. 网络是安全的。近年来，这一在被证明是一条谬论，即使是在公司内部的Intranet内也是如此。不仅黑客可以相当容易的穿透我们的防火墙（例如，防火墙不能防范SQL注入攻击），而且在许多情况下，你也不能相信在网络内部的人们——最近的研究表明，公司损失的70%左右都归咎于雇员的偷窃和诈骗行为。
5. 拓扑结构不会发生变化。对任何IT商店来说都会时常发生的一件事情就是变化。服务器增加了、服务器减少了、机器需要被替换了、硬件需要升级了等等。我们竭尽全力来跟上变化的形式，但是如果我们写的软件能够自动调整以适应变化，那将会很有益处。
6. 只有一个管理员。合并、收购和字串分派只是应用场景的一部分——你还使得进出公司的人达到了警戒水品，包括你的系统管理员。即使你今天有一个应用场景，到了明天就会有一个完全不一样的应用场景。正是因为如此，你需要在构建企业系统时牢记管理、部署和监视。而且，随着PC数量的增长，以及自己动手开发的程序的普及分发，不用提及像章鱼触手一样延伸的伙伴关系在商业中变得向当地常见，就是任何一个团队、部门、甚至公司拥有一个程序的假设都在发生变化。现在问题的关键是，你构建的任何应用都可能转变为另一个完全不同的公司所依赖的某些事物，而你却并不了解该公司。所以你不能假设你拥有自己的数据库，或是有随意改变构件接口的特权。
7. 传输的代价是零。对象通过网线传输并不容易。事实上，在Java中，除了原始类型之外，其他对象通过网线传输的在线表示都是同构的。者意味着这要超出将实际的二进制位通过网线推送出去所需要的开销，你还需要合并一大堆的数据位，以打包和解包数据本身，正是因为这个原因，请关注你要产生的在网络上来回的数量，使用的技术包括成批传递数据以使得每一次在网络上的来回显得更有价值。
8. 网络是同构的。当你停下来去思考.NET迅猛地普及势头，与大量现有的用Python、Perl、C++以及其他语言编写的系统并存的现象时，会很容易的认识到系统级别上的同构性比硬件级别的同构性更不可能实现。因此，你需要仔细考虑在你的架构中的提供商的中立性，并且无论如何都要实现在当前去构建它，你可能在以后会无法拥有他的某些部分。
9. 系统是整体式的。尽管可能在早期的系统中确实是这样，但是关键是一个企业系统经常以某种方式与其它系统集成在一起，即时它们是访问相同的数据库。特别是在今天，系统的不同部分是在不同的时间被修订的（表示层变化了而业务逻辑却保持未变，反之亦然）。这使得认识到系统不同部分需要被部署，以及进行版本控制，而且在很多情况下，他们被彼此独立的开发的这一事实，比以往任何时候都重要。因此，你希望支持基于构建的设计，并指望构建彼此间松散耦合的构件。
10. 系统是可以结束的。企业经常转换业务，并且经常改变环境。只有当你认为你已经完成了某件事时。商务专家会跑过来提出一些新需求或是一些对你刚刚做完的事情的变更。这正是为什么会产生拓扑结构变更以及为什么系统不能保证长期的同构的原因。
----摘录自Ted Neward关于企业级应用开发