什么是Clean Architecture
The Clean Architecture是《Clean Code》作者Uncle Bob提出的一种架构。
开发高质量的软件一直是复杂而又困难的。因为高质量的软件设计不仅仅要满足当下的需求，更需要强壮、易于测试、强延展性。
The Clean Architecture正是一个满足高质量软件设计的架构。其主旨为
• 框架的独立
• 易于测试
• UI的独立
• 数据源的独立
• 业务的独立
这篇文章关于The Clean Architecture的介绍到此，具体内容可以自行查询。
我的实践
我为什么应用实践The Clean Architecture
1. 因为我看到关于Clean Architecture的文章的时候项目青黄不接，我想搞事情。
2. 我被它能干的事儿吸引
3. 我所经历的Android程序设计混乱得令我感到绝望（后来我称采用架构之前的Android开发为黑暗时代）
4. 当时并没有真正理解到它的核心，但我是一个先做起来的人
我怎么把The Clean Architecture这个普适的思想用在Android开发上
在进行开发时我主要参考了
•文章Architecting Android...The clean way?
• 项目Android-CleanArchitecture
核心使用到的工具包含
• Retrofit
• RxJava
• Dagger
如上图，整个项目最终分为了6个Module：
• cleanarchitecture:这个Module是一个Java Library。包含实现The Clean Architecture的基本类，如Executer抽象，Presenter抽象等。
• domain:这个Module是Java Library。包含了核心业务的抽象。
• data:这个Module是Android Library。包含了核心业务相关的实现。
• framework:这个Module是Android Library。是上拉更多下拉刷新、JSON等通用组件的抽象实现。
• customer:这个Module是Android App。是这个项目的其中一个APP
• merchant:这个Module是Android App。是这个项目的另一个APP
结果怎么样
我可以负责任的说：“效果拔群”。从几个方面来说：
1. 业务抽象。公司的核心业务完全抽象到了Domain。各个App基于核心业务进行应用业务的演绎。
2. 结构层次清晰。整体的结构非常清晰。上帝的归上帝，凯撒的归凯撒。
3. 抽象与实现分离。data与domain分离，想用file用file，想用cloud用cloud，想用db用db
我获得了什么
经过刺激又新奇的实践。这个架构带来了上文提到的三个好结果。其中第一个“业务抽象”让我想到了一些不同的东西。
关注点
从前
从前开发关注点放在当前sprint的需求、业务上。很多开发者只知道当前要做的，顶多了解未来也许要做什么，这个需求也许来自于客户，也许来自于产品经理。那么对于这些开发者来说，特别关注当前的需求、当前的业务无可厚非。
现在
我的关注点产生了转变。我的关注点不再是当前需求，当前业务，甚至不再是项目的需求项目的业务。而是核心领域。
什么是公司的核心领域？例如对于淘宝网来说，淘宝卖的是商品；淘宝买的也是商品；天猫卖的是商品；天猫买的也是商品；闲鱼卖的也是商品；闲鱼买的也是商品；商品是包含于核心领域。同样的，订单也是，用户也是。
若在设计系统时，把公司核心领域抽象到系统内。各个业务系统（app）只需要在需求到来时各自演绎。还是以淘宝为例，无论是买家还是卖家，无论天猫、淘宝还是闲鱼，商品就是核心领域的商品，只是在各个业务系统进行不同的展示和操作。这里说道操作，操作也是包含于核心领域的，如“买家取消订单”操作。
我们的关注点从某个业务系统（app）的内容，转移到了公司的业务。这样，我们掌握了公司到底拥有什么，到底会产出什么。只要不改动公司的核心领域，无论产品经理如何演绎，无论如何用户要求多查看一些什么，都在我们的掌控范围之内。
项目积累
成功的政治家必定需要积累政治资本，成功的销售人员必定需要积累客户，在公司供职的开发者当然也需要有所积累。一个项目除了做业务外也需要有积累。
之前我的迷思
有很长一段时间我们尝试抽象各种widget，json什么的，做一套我当时叫做“Android基础设施”的东西，作为公司所有Android项目的基石。后来我们放弃了，随着新的ui设计思想的诞生，新的Android SDK的发布，一切都变得困难而无意义，甚至怨声载道。
我不知道可以积累什么才能具有核心竞争力。
积累核心领域
我们可以积累核心领域。
我们应该不断的积累核心领域，不断的更新同步核心领域。以我对于后端开发有限的了解，他们就是在不断的做这件事，甚至是定义核心领域，那么移动端为什么不能做这个积累呢？为什么移动端一定要被后端牵着鼻子走呢？。
• 如果我们面向核心领域编程（我们姑且把积累公司核心领域叫做面向核心领域编程），那么后端如何实现，对移动端来说不再起决定作用，只是在于移动开发演绎时如何把后端实现的领域接入移动端抽象的领域，因为后端也无法走出领域的范围。
• 如果我们面向核心领域编程，我们可以预见需求，在需求实际提出之前就做好准备。
• 如果我们面向核心领域编程，我们可以独立的对核心领域进行高强度测试。
• 如果我们面向核心领域编程，我们可以快速的开发出新的业务系统（就算是开发个咸蛋也逃不出这个核心领域）
个人要求的改变
为了实现这个积累，对于移动端开发者有了新的（我认为一直存在）的要求
1. 充分了解公司背景与所涉
2. 充分了解核心领域的范围
3. 要想做测试覆盖一样去覆盖核心领域的各个分支
4. 把目光放的比以往任何时候都要远与广
开发流程的改变
为了实现这个积累，开发流程也应该有改变
1. 应该自内而外的开发。先定义核心领域，再在其上进行演绎。
2. 核心领域不应该依赖于业务系统的任何部分，其至于公司实际业务有关。
3. 应该对于核心领域进行高强度的测试。
4. UI开发，工具开发等等都应该服务于核心领域。甚至基于核心领域有预见行的进行UI开发。
我不是一个人
我发现这样想的人并不只有我。也许这样的想法是每个真正理解The Clean Architecture的人都可能会认同的。甚至有人认为这个就是Domain Driven Design。提供一个视频，这是一个项目lead关于Domain Driven Design在Android开发中的例子，他使用的也是The Clean Architecture，内容比较详细，包含了很多细节。
感谢
感谢我这篇文章提到的所有“巨人”，让我脱离了黑暗时代。
感谢能耐心看到这个地方的人。毕竟这篇文章几乎都是字，没有图，也没有‘Show you code’。内容也只是个人的感想，对于大部分人来说枯燥无味。
reference:
[The Clean Architecture]:https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
[Architecting Android...The clean way?]:https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
[Android-CleanArchitecture]:https://github.com/android10/Android-CleanArchitecture
[Domain Driven Design]:https://en.wikipedia.org/wiki/Domain-driven_design
[提供一个视频]: https://www.youtube.com/watch?v=uwJRrJ2Hwqg
本文作者：本文作者：徐珺炜（点融黑帮），成都分公司开发者，负责Android应用开发。是Clean Architecture机构实践者，全栈玩家，最近喜欢看史，已经胖得无法运动了。