1 模块
如下图，在我阅读到的资料中，Clean架构大概被分成三层：
- Presentation Layer
进行界面UI更新的地方，这里采用了MVP(Model View Presenter) 模式，
其工作内容就是接受用户交互，由Presenter的接口实现类去驱动指定业务的Interactor去执行后台任务，取回数据异步更新UI。 - Domain Layer
这里包含了所有业务的Interactor的具体实现，以及所需要的Repository接口。这一层是纯java代码，不依赖任何第三方类库或者Android组件。 - Data Layer
这一层负责 数据的获取，类似MVC/MVP模式中的Model层，由Repository的接口实现类去从网络或者本地中取得数据，提供给外部。而外部不关心Repository的内部实现，只管拿到数据即可。
2 具体流程
- Activity/Fragment 里面持有一个Presenter实例（下文用mPresenter代替），同时Activity/Fragment实现mPresenter的内部类接口View被mPresenter持有。
- 当UI需要获取数据更新界面时（例如 用户下拉刷新列表），mPresenter的作用和MVP模式中的Presenter一样，指示Interactor去从Repository中取得数据（传统的MVP中是指示Model层的实例去获取数据）。获取到数据后，再去通知View层更新UI。
-
Interactor的作用是按照用户交互去对数据进行增删改查，之后异步回调更新界面。具体执行任务的方式是 将代码段扔进线程池中在WorkerThread执行，从指定Repository取得数据，通过MainThread的Handler通知UI刷新。
以上，各个类的触发顺序是：
clean.png
3 优缺点
优点：
1.层次分明，各层级之间都不管对方如何实现，只关注结果；
2.在视图层(Presentation Layer)使用MVP架构，使原本臃肿的Activity(或Fragment)变得简单，其处理方法都交给了Presenter。
3.易于做测试，只要基于每个模块单独做好单元测试就能确保整体的稳定性。
4.易于快速迭代，基于代码的低耦合，只需在业务逻辑上增加接口，然后在相应的层级分别实现即可，丝毫不影响其他功能。
目前的体会：
- 层次分明，不同层之间几乎感觉不到耦合，可以说是我见过各种开发架构中分层级最多的项目
- 开发敏捷，传统的APP开发流程一般是 写界面布局+基本的交互跳转→等后台接口→对接口。而在Clean架构下，由于上文提及的Domain Layer是纯Java Code，所以除去第三方和后台接口以外，我们Android开发者能做的事情已经很多，只需要Repository提供假数据，就可以使整个app运行起来，并且开始界面逻辑业务的测试。
缺点：
- 代码量多，可读性差，缺乏经验的同事（比如我）需要时间上手。