N-Tier
是从架构更大的维度上划分，每一个维度都是一个Tier（在微软的ESP2.0里翻译为”级”），比如电商架构划分如下：
- UI
- 服务接口
- 消息、缓存中间件
- 数据库
- ......
Tier与Tier之间通过Tcp/Http通讯，并且每一级都可以独立部署。
N-Layer
相对Tier，Layer是更细粒度的划分，比如服务接口Tier就可以划分为：表示层、业务逻辑层和数据访问层三个Layer。每一个Layer是没有必要独立部署的，否则只会更影响性能。
总结
Tier一般指物理上的分层，Layer是逻辑上的分层。
分层重要思想
职责分离和关注点分离。
架构拆分的常用方法
- 化整为零
- 动静分离
- 按功能拆分
Anemic Domain Model
贫血型领域模型模式，和Domain Model很像，主要区别如下：
- Domain Model的领域类中包含了自身的业务逻辑和数据，以及对象之间的关系
- 贫血型的领域类将与自身相关的业务处理逻辑全部转移到了模型之外--有专门的业务规则类，这使得领域类成为了一个简单的数据对象。
策略模式
把不同的算法和行文分别封装成独立的对象（类），实现统一的策略接口；具体业务依赖于策略接口，从而可以灵活实现算法、行为的切换。主要解决在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护问题。
装饰者模式
核心思想优先采用组合而不是继承。
模板方法
最直接的理解就是“模板”：包括变化和不变化的两个部分，将变化的部分交给子类实现。一个重要的点就是“钩子”函数，一种被声明在抽象类中的方法（空的和默认的实现），可以让子类自己决定对算法的不同点进行挂钩。
策略模式是除了继承之外的一种弹性方案。如果采用继承来定义一个类的行为，我们将会被这个行为困住，甚至修改起来很困难。有了策略模式，就可以通过组合不同的策略对象来改变行为。
服务定义粒度：
- 不要使用泛泛的UpdateCustomerDetails来定义操作，而要用ChangeCustomerAddress、RecordCustomerMarriage之类的有业务意义的名称来定义操作。操作简单、易于理解，从而提高了易用性。
- 如果服务使用的范围有限，如仅仅在企业内部应用集成，则可以选择相对较细粒度的服务接口，为服务请求者提供更多灵活性，如果服务使用的范围扩大，服务的大小也应随之扩大，如企业外部集成
- 多参数时采用结构化，个人认为超过3个时最好用结构化入参。操作灵活，不干扰现有使用者的情况下提供新版本。
预约保留模式
- 发送一个请求给服务器，从服务端的响应中获取一个预约保留的唯一编号（有一定期限，为了避免资源耗费及一些安全性问题）
- 客户端余下的请求中都会带上这个编号，以便服务器把这些请求当成一个事务来处理
等幂模式
- 每一次客户端请求都被赋予了一个唯一的请求标识（生成规则可能是通过这个请求的一些参数做一些算法来生成）
- 服务端在一个存储区域检查这个唯一的标识所代表的请求是否已经被处理过了，是否有对应的响应信息，如果有就从响应存储设备（如数据库、缓存）中返回响应信息，如果没有再次处理这个请求。