原则1：保守分布
这项原则基于一个事实：调用不同进程上对象的方法要比调用进程内对象的方法慢数百倍；将对象移动到网络中的另一台计算机上，这种方法调用又会慢数十倍。
拿数据层举例，在决定使用数据库时，一般需要决定分布数据源逻辑。然而，决定分布表示逻辑会更复杂一些。首先，除非所有应用用户都使用公共的终端，否则表示层的某些部分就必须颁布到每个用户机上。但问题是分布到什么程度。当然，近来的趋势是在服务器上执行大部分逻辑，而将简单的HTML发送到客户端WEB浏览器。实际上，这正是遵守了保守分布的原则。然而，它也需要每个用户交互都遍历服务器，从而这些用户交互才能产生正确的响应。
在WEB迅速发展之前，普遍的情况是在每个客户机上执行整个表示逻辑，这样可以与用户更快地交互，因为它最小化了服务器上的遍历，但它也需要更新用户接口并被部署到整个用户群。最后，选择使用哪一个客户机基本上与分布设计原则无关，但都与期望的用户经验和部署问题有关。
数据逻辑几乎总是在一个独立的计算机上执行，表示层通常也是如此。现在只剩下业务逻辑，它是整个问题组中最复杂的部分。业务层有时被部署到每个用户，而其他时候则被保存到服务器上。在许多情况下，业务层被分解两个或更多个组件，与用户接口交互相关的组件被部署到客户机处，而与数据访问相关的组件则被保存到服务器上。这就遵守了本地化相关内容的原则。
可以看到，您有许多分布选项。分布的时间、原因以及如何分布等受到很多因素的影响，其中的许多因素又互相竞争。
原则2：本地化相关内容
如果决定或被迫分布全部或部分业务逻辑层，那么应当保证经常交互的组件被放置在一起。换句话说，您应当本地化相关内容。
举例：
在做电子商务中的购物车时，客户组件、商品组件、购物车组件之间就需要多次交互。每一次交互都会带来跨网络方法调用的系统开销。因此，这种跨网络的行为会抵消掉并行处理带来的好处。再考虑到几千用户会同时使用，可想其后果是破坏性的。
应用示例：
可以将应用程序驻留到多台WEB服务器，进口处由负载平衡器来分配，出口都进数据库。该设置称为WEB场。
原则3：使用Chunky接口，而不是chatty接口
Chunky是粗粒度，chatty是细粒度。
粗粒度指方法中传的值用属性表示，细粒度指传的值用对象表示。
在细粒度接口中，被传的方法对象，如果位于客户机进程中，则这个示例不会产生任何问题。可是 ，设想一下每个属性和方法调用跨越大西洋进行遍历，这将会产生严重的性能问题。
原则4：优先选用无状态对象，而不是有状态对象
无状态对象是能够在方法调用之间被安全创建和销毁的对象.如果应用程序选择销毁它,这个动作也不会影响到其他用户.这个特性不是轻易就能实现的,您必须对类进行特殊实现,这样类才不会依赖于公共方法调用之后实例字段是否继续存在.因为对实例字段没有依赖关系,所以无状态对象倾向于使用chunky接口.
通过使用智能缓存、会话管理和负载均衡的方法，可以避免或者最小化使用有状态对象所带来的问题。这就是使用无状态对象的原因，但不是必须使用。这里需要再次说明，这个原则只能应用于为在其他机器中执行的代码所提供的对象。
原则5：接口编程，而不是具体实现的编程
减少频繁的且时常出问题的部署。