深入理解 Android 架构 Clean Architecture（补充篇）_clear arch 架构

在前两篇的介绍篇和解析篇中，我们已经对 Clean Architecture 的核心思想和层次结构进行了初步了解。然而，我发现遗漏了部分知识点，本篇将逐一讲解补充，最后介绍项目实践。

架构图的提炼

在介绍篇中提到的关于 Clean Architecture 图解，其实每一层中都包含了一些我们不需要的东西，因为该架构是一个通用的架构思想，所以在去除掉一些无关的内容后
示例图如下：

数据层中的模型（Model）

数据层不仅由 Repository、DataSource组成，还包含数据模型（Models）。其中模型（Models）扮演着重要的角色。模型是数据层的组成部分，负责表示和处理应用程序中的数据。

Models 定义了应用程序中的数据结构，包括实体的属性、关系等。这可以是网络请求的数据格式、数据库表的映射。

在接口适配器层和用例层之间（绿色与红色），模型可能需要进行数据转换，以适应不同层次之间的需求。这可以包括将数据库实体映射为用例需要的 Domain Model（领域实体）等。

示例：

//网络模型
data class User(
  val name:String,
  val age:Int,
  val gender:Int
  ...
)

//数据库模型
@Entity
data class Note(
  val title:String,
  val content:String,
  val timestamp:Long
  ...
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SOLID原则

SOLID 也是 Uncle Bob 提出的一组设计原则，旨在帮助开发者创建可维护、灵活且易于理解的软件架构，在Clean Architecture 架构中也遵循了这一原则。

• 单一职责原则：一个类应该只有一个引起变化的原因。这意味着一个类应该只负责一种类型的任务，它应该只有一个责任。
• 开闭原则：软件实体（类、模块、函数等）应该对扩展是开放的，但对修改是封闭的。这意味着可以通过添加新功能来扩展系统，而无需修改现有代码。
• 里氏替换原则：子类型必须能够替换掉它们的父类型，而不影响程序的正确性。
• 接口隔离原则：不应该强迫一个类实现它用不到的接口。应该为客户端提供他们需要的接口，而不强迫他们依赖他们不需要的接口。
• 依赖反转原则：高层次的模块不应该依赖于低层次的模块，二者都应该依赖于抽象。抽象不应该依赖于具体实现，而具体实现应该依赖于抽象。

总结

Clean Architecture 提供了一种强大的软件设计理念，其核心思想是通过分层和分离关注点的方式构建可维护、可测试和可扩展的软件系统。将系统分为实体、用例、接口适配器和框架与驱动器四个层次，每个层次有着清晰的责任和依赖规则。这样的结构确保了业务逻辑的纯粹性，使得系统内核独立于外部细节。同时，Clean Architecture 强调了 SOLID 原则的应用，进一步提升了代码的灵活性和可维护性。

这里推荐一个示例项目 SocialNetworkApp，该项目应用了干净架构并使用 Jetpack Compose + MVI实现，通过该示例可以更好的学习干净架构在 Android 中的应用以及每一层的职责体现，欢迎 Star ！

源码地址：https://github.com/AAnthonyyyy/SocialNetworkApp

最后，可以关注一下本人的公众号，会不定期发布一些关于 Android、Kotlin、Jetpack Compose相关的学习笔记和知识。