整洁性架构
众所周知，编写高质量的代码是困难且复杂的，在满足需求的前提下，还要兼具健壮性、可维护性、可测试性和灵活性，以在代码量的增长和需求变化时应付自如。
整洁性架构方案的提出，使得在开发任何软件应用时可能都是的一个很好的架构方案。
整洁性架构方案其实很简单，主要关注下面几个点：
- 独立于框架（无论是系统还是语言）：该体系结构不依赖于一些特征负载软件库的存在。这允许您使用这样的框架作为工具，而不是将系统压缩到有限的约束。
- 可测试性（代码可测性良好）：可以在没有UI，数据库，Web服务器或任何其他外部元素的情况下测试业务规则。
- 独立于UI：UI可以轻松改变，而不改变系统的其余部分。Web UI可以用控制台UI替代，例如，不改变业务规则。
- 独立于数据库：您可以将Oracle或SQL Server，Mongo，BigTable，CouchDB或其他内容进行交换。您的业务规则未绑定到数据库。
- 独立于任何外部媒介：事实上，你的业务规则根本就不了解外界的任何事情。
如图所示，这个图应该关注的时依赖规则：源码的依赖关系只能指向内部，内环的任何内容都不知道任何外部的内容。
分层来介绍图中的角色
- Entities(实体)：这些是应用程序的业务对象。
- Use Cases(用例):这些用例用于协调来自实体的数据流。也被称为交互器。
- Interface Adapters（接口适配器）：这套适配器以用例和实体最方便的格式转换数据（这套的适配器为用例和实体转换数据，转换成最方便用例和实体使用的格式。）
- Frameworks and Drivers(框架和驱动程序)：这里指所有的细节：UI、工具和框架等。
适用Android的整洁性架构
我们的目的是通过保持业务规则不知道外部世界的任何内容来分离关注点，这样才能在不依赖于任何外部内容的前提下实现可测性。
为了达到这个目的，我们的建议是把项目划分为三个不同的层次，每一层次都有自己的目的并且与其他的层次分开工作。
值得一提的时，每个层都是用自己的数据模型，因此可以达到这种独立性（你会在示例项目中看到旨在完成数据转换的数据映射器-Data Mapper，这是不必跨越整个应用去调用模型而保持独立性必须付出的代价）。
这个方案看起来是下面这样的：
Presentation Layer(展现层)
展现层是视图和动画相关逻辑发生的地方。该层中不但可以使用Model-View-Presenter模式(目前使用的MVP模式)，也可以使用如MVC或者MVVM的其他模式。这里不详细的介绍，只需要知道fragments和activities仅仅作为View(视图),这里只有UI(用户交互)的逻辑，是所有渲染工作发生的地方。
此层的Presenters由在工作线程执行任务的交互器(用例)组成， 并返回响应数据交给View去渲染页面。
Domain Layer(领域层)
这里的业务规则：所有的逻辑都发生在这一层。对于安卓项目在这一层你能看到所有的交互器（用例）实现类。
此层是没有依赖任何安卓依赖关系的纯Java模块。所有外部组件当需要和业务对象进行交互时，都使用接口建立链接。如下图：
Data Layer(数据层)
应用程序所需的所有数据均来自此层，通过UserRepository(该接口在领域层中)实现类完成，该实现类采用库模式策略来实现根据特定条件通过工厂选择不同数据源。
例如，当需要通过ID获取一个用户的时候，如果这个用户存在于缓存中，这时磁盘缓存数据源就会被选择；否则的话，将会通过查询云以获取数据，然后后会将得到的结果保存到磁盘缓存中。
所有这一切的背后想法是，对于客户端的数据源是透明的，client不关心数据是从内存磁盘还是云端，唯一的事实是数据可达并且获取到了。
注意：示例代码使用文件系统和Android preferences文件实现了一个非常简单和原始的磁盘缓存，这是为了学习目的。请记住，如果有现有的开源库以更好的方式执行这些工作，您不应该重复造轮子。
可测性
关于测试，我根据层选择了几种解决方案：
- 展示层：使用Android instrumentation和espresso进行集成和功能测试。
- 领域层： JUnit + mockito用于单元测试。
- 数据层： Robolectric（因为这个层有android依赖）加上junit + mockito进行集成和单元测试。
架构响应路径
如下图：
结论
正如Bob大叔所说，"架构关乎意图而非框架"（Architecture is About Intent, not Frameworks），我完全同意这个说法。当然也有很多不同的做法（不同的实现方式），我很确定你同我一样每天面临很多挑战，但是通过使用这种技术，可以确保你的应用程序：
- 容易维护
- 容易测试
- 高内聚
- 低耦合
以上，谢谢大家！
