又到年终了，回顾2015年，感觉收获颇多。进入新的领域后，在设计方面也收获不少新概念，MVP，DDD，微服务等等新鲜出炉的名词，需要梳理总结一番。
一、分层
常见的软件分层是表述层、业务逻辑层、数据层。在java应用中，将数据的访问细节进行封装，在业务层和数据层之间增加了持久化层。
分层架构达到解决方案，小到单个模块都可以使用，然而在面向服务思想逐渐成为潮流的今天，一切皆服务，上述三个层次的划分基本在架构设计上看不到了。但是这并不影响这种划分概念应用于服务内，MVP和MVC就是这种概念的设计模型。
二、MVC和MVP
MVC:Model – View –Control
MVP:Model – View - Presenter
MVC和MVP是常见的应用设计模型，但是在众多模块设计中，不一定都需要直接显示的，因此笔者在设计过程中，将View改成了Interface，变成了PMI和CMI，如下图的SERVICE_A和SERVICE_B。（View其实也是接口，因为UI嘛^_^）
三、为什么要使用MVC和MVP的设计模型？
首要目的是为了解耦，在上图中，服务B提供的内容发生了改变，服务A只需在MODEL中进行兼容处理，而服务A的MODEL提供的内容并未变化，因此服务A的主体逻辑和对外功能都无需改变。（DDD中领域隔离的概念，在下一篇中也会有所描述）
其次则是减负，服务的处理流程一般是接口内容解析、业务请求处理以及处理结果的反馈。如果接口是大而全的函数，则逻辑负担十分沉重。（如果接口处理函数超过50行，就应该考虑整合一下）而通过MVC/MVP的设计模型，可以极好的减轻处理流程的逻辑负担。
还有一个好处是MVC的自演进，后续的变化中会讲到随着需求的演进，MVC也在不断的变化适应。
四、MVC和MVP的差别是什么？
从三的图中我们可以直观的看出两者的差别就在于View（INTF）是否可以直接访问MODEL。从View的角度分析，如果定位View尽量简单，那最好是把事情都交给presenter处理，View无需知道Model的内容，这样Model的变化也就不会影响到View。如果View想够快的响应，那么对于查询配置这些简单处理逻辑内容，View就有可能“越俎代庖”，直接访问Model，避免P/C响应不及时（特别是P/C被设计成独立的线程时）。
因此笔者对MVC和MVP差别的解读主要是解耦和性能的衡量。相对而言，笔者更常用MVC模型，因为笔者比较直接^_^，另一方面则是业务逻辑太复杂，实在不忍心增加P/C的负担T_T。
三、变化
需求在不断变化，有一类需求是优化无止境的，那就是快，所有请求都希望被尽快处理，至少不要让使用者被堵塞住，因此MVC开始出现变化。（以下变化案例全部源于基站多模系统的设计理念）
1、服务无API，服务只能通过消息访问。如果有多个应用需要使用服务，则服务内的同步锁会导致多个应用被堵塞，这是难以忍受的，因此通过消除API，可以避免应用直接被服务锁住。
2、P/C/M服务化，对于View（INTF）来说，一切皆服务（微服务概念）。举个例子，某个服务根据不同设备设计数据传输流量，要求上层调用者的数据传输流量要适配其要求。这时候，需要上层的调用者大改？其实不用，只需要在MODEL里适配即可，INTF将所有数据交给MODEL，MODEL启动后台任务完成流控，对View来说MODEL就是服务。
3、由数据驱动。真正的快是怎样的？任何请求，我只改数据，对数据校验通过后，我存入数据库就可以反馈了，至于数据库的变化如何触发其他业务逻辑，则不再关注。这种设计让INTF与LOGIC解耦，响应可以达到非常快的速度，但是有一个前提是业务逻辑基于数据的处理基本不会异常，在小概率异常的情况下，由上层往下进行后处理。（如下图，INTF写，LOGIC读，如果LOGIC反写数据库，存在很大风险）
4、SERVICE之间无接口。所有的交互只是数据，服务间再无依赖。MODEL间的同步是标准协议，所有服务都可以独立演进，发布，替代，只需要确保MODEL遵守标准即可。
