分层架构的演进

之前做过一次以解决问题为动机，迭代架构的分享。这次是从架构演化的角度解释架构。
虽然角度不同，但是最终得到的架构结果是相同的。

架构的工作

架构可以细分为

代码架构：关注怎么写高质量代码
工程架构：关注怎么快速的迭代开发产品

代码架构

梳理业务逻辑，定义业务模型，业务服务
整理出清晰的表示层，业务层，持久层边界
持久层实现方案

工程架构

组件化业务模块
重构项目源文件结构，优化团队协作（实现aar,module等工作）
优化编译，发布流程

代码架构有哪些

谈起架构，经常会听到分层架构，三层架构，clean架构，MVC,MVP,MVVM，他们之间有什么关系呢？

架构的核心是分层，三层架构是分层思想的具体实现，clean架构也是分层思想的具体实现，不过相比三层架构各个角色的描述更加详细。
MVC,MVP,MVVM只是分层架构中实现表现层的一种设计模式。

分层架构

分层架构的优点
（1）开发人员的专业分工，专注理解某一层。
（2）可以很容易用新的实现来替换原有层次的实现。
（3）降低了系统间的依赖。
（4）有利于复用。

三层架构

服务端的SSH框架中的三层架构实现示意图

依赖规则：依赖接口，从上到下单向依赖

架构的问题

登陆时需要获取用户昵称，签名，年龄，帖子个数信息。
version 1: 登陆时，客户端会请求四次网络

interface UserService {
    public String getUserName();
    public Int getUserAge();
    public String getUserSignature();
}

interface PostService {
    public Int getPostCountByUid(int uid);
}

问题：客户端使用起来不仅繁琐，而且多次网络请求消耗手机性能

version 2: 客户端只调用一个聚合后的接口

interface LoginService {
    public LoginInfo getLoginData();
}

问题：客户端需求版本升级，或者支持一个新的App登陆，现在登陆只需要获取昵称，年龄，帖子个数。那么现在这个登陆接口就不能用了。于是我们会

直接修改getLoginData()方法
在LoginServcie中新增一个方法

但不管哪种做法，都在编辑了老文件，都破坏了开闭原则。

观察发现上面的代码有一个特征：UserService,PostService中的方法是不会变化的，但是LoginService中的方法会随不同的App,不同版本的App发生变化。那么该如何管理这部分的代码呢？

四层架构

User Interface: 用户交互界面，等同于上面的表示层
Application: 应用层，定义软件要完成的任务。
Domain: 领域层，负责业务概念，业务规则的实现。
Infrastructure: 基础实施层，向其他层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。

解决的问题：

分离通用的企业业务和特定的应用业务
分离业务逻辑和技术细节，Domain是核心的业务逻辑，Infrastructure是技术细节

clean架构

clean架构是四层架构细想的更详细的实践指导，明确的定义了角色名称

Entities：领域层业务，Enterprise Business Rules
Use Cases: 应用层业务, Application Business Rules
明确的定义了GateWays,Controllers,Presenters等业务层和展示层适桥梁的中间角色。

依赖规则

依赖接口，从外到内单向依赖。内部不知道外部的任何规则

Android中的clean架构具体实现

根据上图可以划分为四个Moduel:

UI:界面
DB:数据存储实现细节
Device:设备，平台相关功能实现细节，如同步硬件数据，通知等
业务逻辑

但是如果真的这样去执行，可能会有过度设计的效果，对这个四个moduel进一步进行重构分析。

由于DB,Device，UI是和应用相关的，不同的应用实现细节可能不同，所以把四个Module分为两类：

应用层（App）: UI,DB,Device.
业务层(Domain): Application Business Rules, Enterprise Business Rules.

如果多个应用中DB,Device技术实现细节相同，则将代码下沉到业务层(Domain)中。
注意，DB,Device代码上还是通过package和UI层区分开的，只是工程管理上把他们放在了应用层(App)。

yeshu blog