【笔记】软件结构模式-分层结构

分层模式 

适用条件：
        应用可被分解为多个子任务组
        每个子任务组处于特定抽象层次上
        接口应该是稳定的，甚至可以有标准协议来限定
设计要点：
        合理分层：
                定义合适的抽象层数
                层J 提供由层J+1使用的服务，同时委派任务给层J-1 。
                较多的服务放在高层往往比低层好，避免开发人员面对只有细微差别的原语
                通常高层关心相邻的低层，但低层并不关心用户的身份
                层间彼此要严格分离，注意避免层间的共享模块导致放松严格分离原则

        层间通信：
                Push Mode：层J使用层J-1的服务时，任何要求的信息可以作为服务调用的一部分来传递
                Pull Mode：低层自行从高层获得信息，可以考虑使用publisher-subscriber 模式，缺点是导致低层对高层的依赖。

        回调函数：

                对自底向上通信，可以使用回调函数而避免破坏自顶向下的单路耦合。这里高层要注册低层的回调函数，当低层可能发往高层的事件集固定时，这种设计特别有效。Reactor模式给出了回调使用与事件分路传输相结合的一种面向对象实现方式。 Command模式给出了如何把回调函数封装成第一类对象。

        错误处理：
                错误尽量在它出现的层内处理，以防止高层被许多不同错误和大量错误处理代码陷入困境
                向更高层通知错误时，应试着把相似错误类型归并成更一般的错误类型，避免高层面对赢了高层不能理解的低层错误。

反模式：
        污水池：如果我们的请求经过分层而没有做任何事，这就是污水池反模式的征兆
        巨石应用（Monolith）：将分层应用打包成巨石，可能导致扩展困难

优缺点：
        结构清晰：分层隔离有利于降低整个应用程序的复杂度
        可测试性：使用Mocking和Faking，每一层可以独立测试
        灵活性：接口定义良好的层很容易被语义上等价的实现替换掉。用桥接模式支持一个层提供的服务的多重实现， 策略模式用于一个层使用的算法动态替换， 用适配器让不同接口的实现替换一个层的服务

        性能问题：因为请求需要经过多个分层，可能会存在性能问题

        可伸缩性差：耦合太紧，很难对分层应用程序进行伸缩
        不必要的工作：低层执行的某些任务可能是高层不需要的或者重复的。
        难以认可层的正确粒度  层粒度的确定和层任务的分配是比较困难的
        

应用实例
        三层B/S结构（表现层-领域层-数据源层）
        OSI七层网络模型

变体： 
        松散分层系统：每一层可以使用比它低的所有层的服务。提高灵活性的同时降低了可维护性。
        通过继承分层：优点是高层可以根据需要修改子类服务。缺点是继承关系造成高层与低层的紧耦合。