16年底，笔者第一次接触了Clean Architecture的开发框架，虽然虽然不甚理解，但还是模仿着github上的demo开发了公司内部使用的一个小项目。使用后觉得不错，之后也用它陆陆续续开发了几个小的项目。本篇主要记录一下此时的一些小体会。

依赖关系

 说到Clean Architecture，就一定会提到这张依赖关系图：

Clean Architecture依赖关系

如图所示，外层依赖里层，里层不依赖外层。最外边的两层（UI以及Presenters）是视图层，用来呈现数据并与用户交互。中间（UseCases）是业务层，是执行业务逻辑的地方，这里一般执行，从不同数据源中获取数据的任务。最内层（Entities）是数据部分。

结构

上面是该框架的概述，真正看Demo操作时可能会有疑惑，因为在实现的时候时分为如下三层：Presentation层、Domain层、Data层。其中Domain虽然一般翻译为中间层，因为Presentation层内是通过这一层和Data层建立关系的，但它其实担任的是上图中最核心的部分。如果将这三层作为分别作为单独的模块（Module），它们的依赖关系会是：Data依赖Domain，Presentation依赖Data和Domain。

笔者在安排这三层的内容一般是这样的：

三层结构

Domain层

1.核心层，不依赖其它层。它只是数据本身。如果说这层还涉及到数据的增删改查工作，也只是逻辑上或者概念上的，具体执行都是由Data层完成的。这层只是提供了若干接口。

2.数据的结构或类型放在这层，例如用户信息类UserEntity。

3.数据之间的相互转换方法在这层，例如提供将String类型转换为UserEntity的方法。

4.其他两层交互的逻辑（UseCase）以及接口在这层。例如从网络中获取用户信息这个逻辑，这个请求一定是由Presentation层发起的，Domain层牵线搭桥，具体执行网络请求的是Data层，并再通过Domain层返回Presentation层。

Presentation层

1.视图层，Android所有Activity、Fragment等等与用户交互的都在这里完成。

2.接收Domain层传来的数据并呈现给用户，将用户操作产生的信息再传会给Domain层。

Data层

1.处理全部数据相关的逻辑，譬如从不同的信息源获取或发送保存信息，信息源可能是网络、数据库，文件，蓝牙等等。

2.Data层实现了Domain层的接口，也即，Domain层对数据的操作最终是Data层完成的。

骨架

上面的内容简述了Clean Architecture的各个层次。这三个层是怎样协作起来的呢？我认为下图是该框架的精髓所在：

Clean Architecture的数据流

访问的信息由上Presentation层经Domain最终到到底Data层，返回的信息反向由底层传至顶层。其中传递的方式当然使用了RxJava以及RxAndroid。Presentation层是数据的订阅者（Subscriber），Data层是数据的被观察者（Observable），二者通过Domain层产生订阅关系。这就是Clean Architecture完成的核心内容：

将UI、业务逻辑、数据分别作为Subscriber、订阅、Observable三者进行拆分

结果就是使每个部分具有低耦合度，可以分别独立开发、测试，同时也提高了各个模块的复用性。

以上内容均代表笔者个人愚见

本文的全部图片引用自https://github.com/android10/Android-CleanArchitecture