面向接口编程
一般在实现一个系统的时候,通常是将定义与实现合为一体,不加分离的，我认为最为理解的系统设计规范应该是所有的定义与实现分离，尽管这对于系统中某些复杂的情况有些繁烦。
面向接口编程设计
使用面向接口编程思想将层与层之间通过接口依赖,下层不是直接给上层提供服务，而是定义一组接口供上层调用。至于具体的业务实现，是开发中需要做的事情，在项目架构阶段，只需要定义好层与层之间的接口依赖,将框架搭建起来,编译可以直接通过。
为什么要有面向接口编程设计？
为了提高架构的灵活性,降低层和层之间的依赖(耦合)
在一个系统框架中一个接口层可以根据不同的业务对应的有不同的实现层提供服务。
举个例子 多层架构中,前后端分离的情况下前端只做一些弱逻辑处理，表现层只控制网络请求的输入输出(通过IBLL接口和业务逻辑层依赖),业务逻辑层执行和处理强逻辑,对应不同的业务可以编写不同的服务(IBLL接口 提供Bll.pc或者Bll.mobile多套服务)供表现层调用，
数据持久化层一般只做一些原子性的操作
数据持久化层大部分使用关系型数据库,也有使用搜索引擎的还有文件系统,非关系型数据库的
依赖倒置
在软件设计原则中，有一种重要的思想叫做依赖倒置。它的核心思想是：不能让高层组件依赖底层组件，而且，不管高层组件和底层组件，两者都应依赖于抽象。
那么，这个原则和我们上面的原则是否矛盾呢？其实并不矛盾。
因为这个原则定义中的“依赖”是指“具体依赖”，而上面定义中的依赖全部指“抽象依赖”。我对这两种依赖的定义如下：
具体依赖——如果P层中有一个或一个以上的地方实例化了Q层中某个具体类，则说P层具体依赖于Q层。
抽象依赖——如果P层没有实例化Q层中的具体类，而是在一个或一个以上的地方实例化了Q层中某个接口，则说P层抽象依赖于Q层，也叫接口依赖于Q层。
依赖注入:
我们设计的分层架构，层与层之间应该是松散耦合的。因为是单向单一调用，所以，这里的“松散耦合”实际是指上层类不能具体依赖于下层类，而应该依赖于下层提供的一个接口。这样，上层类不能直接实例化下层中的类，而只持有接口，至于接口所指变量最终究竟是哪一个类，则由依赖注入机制决定。
层次划分：
目前，典型的分层架构是三层架构，即自底向上依次是数据访问层、业务逻辑层和表示层。
职责划分：
目前，在典型的三层架构中，对层次各自的职责划分并没有一个统一的规范，综合现有的成功实践和.NET平台的特殊性，在本文中将三层架构的职责划分如下：
数据访问层——负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。
业务逻辑层——负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。
表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。
在一个系统框架中一个接口层可以根据不同的业务对应的有不同的实现层提供服务。
举个例子 多层架构中,前后端分离的情况下前端只做一些弱逻辑处理，表现层只控制网络请求的输入输出(通过IBLL接口和业务逻辑层依赖),业务逻辑层执行和处理强逻辑,对应不同的业务可以编写不同的服务(IBLL接口 提供Bll.pc或者Bll.mobile多套服务)供表现层调用，
数据持久化层一般只做一些原子性的操作
数据持久化层大部分使用关系型数据库,也有使用搜索引擎的还有文件系统,非关系型数据库的