业务逻辑应该清楚地分开并且独立于框架
先看下我们熟悉的MVP架构
再看下我们熟悉的MVP+管理类
提前预览下Clean的架构
再来看下真正的主题 Android Clean
它也被称为洋葱架构，因为该图看起来像一个洋葱（当您意识到必须写多少样板时，它会让您哭泣）。或端口和适配器，因为如您所见，在右下角有一些端口。六角形架构是另一种相似的架构。
清洁架构是先前提到的Bob叔叔的创意，他还撰写了有关Clean Code和Clean Coder的书。这种方法的要点是，业务逻辑（也称为域）位于宇宙的中心。
依赖规则
外层应取决于内层。红场中的三个箭头表示依赖性。与其说“依赖”，不如使用“看见”，“知道”或“知道”之类的词。用这些术语，外层可以看到，知道和知道内层，但是内层既看不到也不知道，也不知道外层。如前所述，内层包含业务逻辑，外层包含实现细节。结合依赖规则，可以得出结论，业务逻辑既看不到也不知道，也不知道实现细节。而这正是我们正在努力实现的目标。
抽象化
以前已经暗示过抽象原理。它说，当您朝图的中间移动时，内容变得更加抽象。这是有道理的：正如我们所说的，内圈包含业务逻辑，外圈包含实现细节。
如图所示，您甚至可以将相同的逻辑组件划分在多个层之间。可以在内层中定义更抽象的部分，而在外层中定义更具体的部分。
您可以在该图中看到标准三层体系结构中的所有依赖关系都进入了数据库。这意味着抽象和依赖关系不匹配。从逻辑上讲，业务层应该是应用程序的中心，但并不是，因为依赖关系会进入数据库。
在干净的体系结构中，依赖项进入业务（内部）层，而抽象也向业务层发展，因此它们匹配得很好。
这很重要，因为抽象是理论，而依赖是实践。抽象是应用程序的逻辑布局，而依赖关系是应用程序实际组合在一起的方式。在干净的体系结构中，这两个匹配，而在标准的三层体系结构中，它们不匹配。如果您不小心，可能很快导致各种逻辑上的不一致和混乱。
层间通讯
现在，我们已经将应用程序划分为模块，将所有内容很好地分离了，将业务逻辑放在应用程序的中心，而实现细节则在郊区，一切看起来都很棒。但是您可能很快就遇到了一个有趣的问题。
如果您的UI是实现细节，互联网是实现细节，并且业务逻辑介于两者之间，那么我们如何从互联网上获取数据，通过业务逻辑传递数据，然后将其发送到屏幕？
业务逻辑位于中间，应该在Internet和UI之间进行调解，但它甚至不知道这两个家伙是否存在。这是通信和数据流的问题。
我们只有两层，绿色一层和红色一层。绿色的一个在外面，知道红色，红色的一个在里面，只知道自己。我们希望数据从绿色的一到红色的一再回到绿色的一。解决方案之前已经暗示过，并在下图中显示：
右下角的图部分显示了数据流。数据从控制器输入，通过用例（或用您选择的组件替换用例）输入端口，然后通过用例本身，然后通过用例输出端口返回到演示者。
输入端口是一个接口，实际的实现是用例：因此它在用例上调用了一个方法，数据流到该用例。用例做了一些事情，想将数据发送回去。它具有对输出端口的引用（因为输出端口是在同一层中定义的），因此它可以在其上调用方法。因此，数据进入输出端口。最后，演示者是或实现输出端口。那是神奇的部分。当它实现输出端口时，数据实际上流入其中。
定义其输入和输出端口是内层的责任，以便外层可以使用它们与之建立通信。我们在内部层定义了一个通知接口，业务逻辑可以使用该接口向用户显示通知，但是在外部层也定义了一个实现。在这种情况下，通知接口是业务逻辑的输出端口，它用于与外部世界进行通信-在此示例中为具体实现。
Clean架构图的模块对应
所有这些都按模块级别，包级别和类级别整齐地分开。因此，应该满足SRP
我们已尽可能将Android和现实世界中的东西推向郊区。业务逻辑不再直接接触Android。
Clean可以更方便的进行分类测试
Clean可以更清晰的对各个着重方向进行关注
依存关系
依赖性规则定义具体模块依赖于更抽象的模块。
UI（app），DB – API（数据）和Device（设备）东西在外圈中。意味着它们处于相同的抽象级别。那么我们如何将它们连接在一起？
理想情况下，这些模块将仅取决于域模块。在这种情况下，依赖项看起来有点像星星：
但是，我们在这里使用Android时，事情还不能完美。因为我们需要创建对象图并初始化事物，所以模块有时依赖于域以外的其他模块。
例如，我们正在为app模块中的依赖项注入创建对象图。这迫使应用程序模块了解所有其他模块。
我们调整后的依赖关系图：
Clean是一把双刃剑
优点
- 测试就变得更加容易
- 漏洞更容易被隔离
- 新功能也很容易添加
- 代码更易读和可维护
- 单向依赖、数据驱动编程
缺点
- 结构复杂
- 粒度太细
- Usecase 的复用率极低
- 急剧的增加类和重复代码
总结
遵循这些准则，我们创建了一个健壮且通用的体系结构。乍一看，它看起来像很多代码，确实如此，但请记住，我们正在为将来的更改和功能构建体系结构。如果操作正确，将来您将心存感激。
个人感觉Clean架构更适合多人协同的大项目，不然有点杀鸡用牛刀的感觉。
