通常一個軟件系統都包含不同部分互相交互耦合，我們希望設計能夠將系統划分為有意義的各個部件，各個部件能夠獨立的開發、演進、部署。這時整體性的設計已經無法滿足這些挑戰，這就需要我們對系統進行合理清晰的划分。通常我們為待開發的系統定義多個層次，每一層完成獨立的功能。
設計原則：
1：系統分為多層，每層完成獨立的功能，層內部繼續細分子模塊，每層能夠獨立演進、部署。分層原則可以基於業務抽象、硬件、變化性等來划分，比如sqlite就是基於業務抽象來進行分層的。實際的框架設計可能同時結合多種維度比如常見的表示層、邏輯層、數據層就結合了業務抽象和變化兩個維度。
2：各層的功能基於同層和底層的功能之上，如圖所示L1的所有功能基於本層、L2、L3（實際設計中不建議基於跨層功能），也就是說上層只能調用本層和下層的接口。這樣的設計避免互相調用導致的結構復雜。
3：各層提供相應的接口與實現分離，對該層的訪問只能通過接口進行。通過接口進行訪問有效的分離了關注點。外層關注接口，層內部關注接口的實現，實現的修改不會對其它層產生影響。實際應用中可以使用適配器模式來有效的分離接口和實現。假設業務數據可能通過不同的協議棧承載實際數據的傳輸，不同的協議有不同的實現，我們可以如下設計接口：
上層使用如下數據傳輸接口：
struct transportDescription { int (*receiveData)(void*privateConnectionInfo,void*buffer,int bufferLen,); int (*sendData)(void *privateConnectionInfo,const void *buffer,int bufferLen); }
下層提供協議注冊接口：
int initializeTransports(transportDescription* pTransInfo);
#ifdef _HTTP_ #define initializeTransports HTTP_initializeTransport #endif #ifdef _WSP_ #define initializeTransports WSP_initializeTransport #endif
上層應用通過調用initializeTransports注冊承載協議，上層只需要調用receiveData、sendData 接口進行數據收發，下層協議信息對上層完全透明，通過定義不同的協議宏可以在不同的協議間切換而不影響上層的實現。
4：底層不能依賴高層的功能，這樣設計避免了結構的復雜，你不能指望操作系統來調用你的接口吧。但是一些系統的事件確實需要上層應用做出相應的處理，該如何處理呢？這就需要用到觀察者模式了，在C語言中一般通過回調機制來實現，這時下層提供接口，上層把實現注冊進去。這樣底層就可以在不調用上層的接口下控制上層的行為了。
5：數據流是雙向交換的，比如在協議棧中數據可以在相鄰的層次之間交換的，下層到上次的數據流可以有多種方式比如消息機制、回調機制等。消息機制有利於分布式部署並且是一種松耦合的形式，只要接收雙方定義了消息格式即可，不再需要依賴具體的接口。
分層架構通過對關注點的分離有利於分化系統的復雜性，提高系統的可擴展和可維護性，但在分層架構中為了獲取底層的功能可能需要進行多個層次的傳遞，不可避免的導致性能的下降。為了保持架構的穩定在開發中增加功能往往需要在各層都要添加相應的代碼。