一、概述
简单来讲业务SDK就是给业务module(UI层)服务的,给UI层暴露Domain Layer(给UI调用的接口及交互用的Pojo)。换句话说SDK层对外只暴露Domain Layer(有限的接口和pojo),UI层和SDK层只通过接口进行交互。
对于业务SDK来讲,它主要包含两部分:Data Layer(数据的本地存取+网络存取)和Domain Layer。

二、从整洁架构来理解Android架构分层
1、什么是整洁架构?
简单来讲整洁架构的主要目标是为了提升组件(模块)的复用性,提升代码的可维护性给开发者约束代码边界的一套参考标准。它的优化目标是组件。
上图显示了整洁架构的示意图,其中每个同心圆层代表了软件开发中的不同层,越是靠近中心,同心圆层所代表的东西越抽象。可以这么理解,内部的圆层定义的是规则,外部的圆层定义的是实现机制。
1.1、组件分层简介
- 实体(Entities)层:关键业务数据和业务逻辑的集合,与界面无关、与存储无关、与框架无关,只有业务逻辑。
- 用例(Use Cases)层:特定场景下的业务逻辑,可以理解为 输入 + 业务实体 + 输出 = 用例。
- 接口适配(Interface Adapters)层:主要包含各种适配器,负责把从实体层和用例层流出来的数据转换成为更外面一层需要的数据格式。
- 框架与驱动(Frameworks and Drivers)层:这是最外面的一层,是很多工具(或库)的具体实现细节所在层,比如 Web 框架(考虑一个应用可以做成网页版应用,也可以做成单机版应用)、数据库工具包(考虑各种 ORM 的实现,以及各种数据库的驱动依赖包实现)等。
值得说明的是,虽然整洁架构的示意图中只显示了四层结构,但是可以根据业务规模调节层数,也就是说层数不是关键,关键在于分层思想以及依赖规则。
1.2、整洁架构的优势
整洁架构试图有这样几个优势:
1)框架无关,即架构设计不依赖任何一个既有的开发框架,因此理论上可以使用任何框架来实践整洁架构。
2)业务规则的可测性,即可以方便地测试业务逻辑所涉及的代码,不依赖UI、数据库或者 Web 服务等外部元素。
3)功能实现不依赖 UI 的实现细节,比如同样一套后台系统可以用在 Web 应用,也可以用在 App 原生应用。
4)业务逻辑不依赖数据库的实现细节,可以把数据保存在 Oracle、SQL server、Mongo、Mysql 等任意一种数据库中,同时业务逻辑不需要做任何改变。
总结起来就是:业务逻辑对外界实现完全没有依赖,任你外面的实现细节如何改变,核心业务逻辑不需修改。
1.2、组件之间依赖规则
依赖规则:只允许外部圆层的代码依赖内部圆层的代码,反之则禁止。换言之,内部同心圆层的代码不知道任何外部同心圆层的代码,比如内层的代码一律禁止引用外层声明的函数、类、变量或其他任何元素。
数据流向规则:当有数据传递时,只允许外部圆层接受内部圆层的数据格式,反之则不允许。这也是为避免外部的代码逻辑影响内部的代码逻辑。
三、Android上的整洁架构
如下图所示,与谷歌的架构图基本一致,分为UI Layer(Activity、ViewModels、Fragment)、Domain Layer(Server Data Models、UseCases)和Data Layer(业务接口实现、数据转换器/Mappers(server data/db entity转为UI上需要的pojo)
1、如何与整洁架构中的分层对应上呢?
UI Layer:整洁架构中的Interface Adapter层(ViewModel)+Frameworks and Drivers层(Activity、ViewModel、Fragment)
Domain Layer:整洁架构中的Entities层(Server Data Models)+UseCases层(UI层调用的接口+接口上传输的Pojos/给UI层用的pojo)
Data Layer:整洁架构中的Frameworks and Drivers层
Implementation of Domain InterFace:UseCases具体,实现比如本地数据/网络数据存取。
Mappers(网络数据转为UseCases中需要的pojo)
2、如何理解Domain Layer?
2.1、从整洁架构去理解
如上图所示Domain Layer其实就是整洁架构中的Entities层和UseCases层。提供了UI层的调用入口/接口。
2.2、从谷歌架构指南中的Domain Layer去理解
架构指南中有这么一段话
网域层是位于界面与数据层之间的可选层。
网域层负责封装复杂的业务逻辑,或者由多个 ViewModel 重复使用的简单业务逻辑。此层是可选的,因为并非所有应用都有这类需求。请仅在需要时使用该层,例如处理复杂逻辑或支持可重用性。
该层中的类通常称为用例或交互方。每个用例都应仅负责单个功能。例如,如果多个 ViewModel 依赖时区在屏幕上显示适当的消息,则您的应用可能具有
GetTimeZoneUseCase类。网域层具有以下优势:
- 避免代码重复。
- 改善使用网域层类的类的可读性。
- 改善应用的可测试性。
- 让您能够划分好职责,从而避免出现大型类。
如需详细了解此层,请参阅网域层页面。

具体示例如下:这里用NewsRepository和AuthorsRepository去组合界面要显示的数据(每个ArticlePojo即包含news也包含author)
class GetLatestNewsWithAuthorsUseCase(
private val newsRepository: NewsRepository,
private val authorsRepository: AuthorsRepository,
private val formatDateUseCase: FormatDateUseCase
) {
private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
}
class FormatDateUseCase(userRepository: UserRepository) {
private val formatter = SimpleDateFormat(
userRepository.getPreferredDateFormat(),
userRepository.getPreferredLocale()
)
operator fun invoke(date: Date): String {
return formatter.format(date)
}
}
2.3、异同点
相同点:都起到了隔离作用,把UI层和数据层做了隔离
不同点:依赖方向两者是反着的
3、如何理解Data Layer?
3.1、从整洁架构中去理解
如上所述整洁架构中的Data Layer其实属于圆环中的最外层,是Domain Layer中接口的具体实现。
3.2、从谷歌架构指南中的Data Layer去理解
如上所述Data Layer包含两部分:DataSource(数据来源)和Repository(给Domain layer暴露的接口)
如下图Data Layer主要是给UseCases提供数据存取服务(这里的箭头表示交互逻辑)
3.3、异同点
相同点:都包含了DataSource,即都有数据存取的具体实现
不同点:整洁架构中的Data Layer依赖Domain Layer,谷歌架构指南中的Domain Layer依赖Data Layer
4、谷歌架构指南是整洁架构么?
答案是肯定的,架构中分层没有绝对的,要结合项目实际情况去做调整。
谷歌架构指南中Domain Layer会向界面层提供依赖项,而它自身依赖于数据层,这个与整洁架构中的Domain Layer分层是不一样的,整洁架构中Domain Layer处于最内层的一环,本身不依赖任何模块。谷歌这种架构方案其实更多类似于一个融入了整洁架构思想的QuickStart式的架构指南。
四、 我们自己的业务sdk要怎么分层?
如上图所示我们的业务SDK主要分为两层:
- 1.SDK入口:其实就是安卓整洁架构中的Domain Layer,如sdk_user_api,只暴露API接口(UseCases)和pojo。
- 2.SDK模块:其实就是安卓整洁架构中的Data Layer,包含了SDK API的具体实现
参考资料:
Detailed Guide on Android Clean Architecture