Clean

这张图描述的是整个软件系统的架构#xff0c;而不是单体软件#xff0c;其中至少包括服务端以及客户端…Clean

Android

这张图描述的是整个软件系统的架构而不是单体软件其中至少包括服务端以及客户端。

Android

我大概总结了一下过往的开发经验找出了应用架构中的重要部分然后绘制了下面这张

Clean

架构基本准则是源码级别的内层不依赖外层依赖关系永远是单向的外层向内层依赖。

如上Model

为了达到这种源码级别的依赖关系我们必须借助一些工具来实现依赖注入一般可以使用

Hilt

另外依赖注入不应该被滥用不是所有的对象都适合用依赖注入只有那些有明确层次关系的模块互相有着明确的依赖关系的才需要。

对于一些工具类显然是没必要注入的。

Model领域模型

业务模型或者叫领域模型是根据软件业务设计出来的具体模型一般来说会是个

data

由于是在整个架构的最内层所以不依赖任何其他模块并且相对稳定设计的时候需要考虑这点。

如果模型发生变化那意味着整个上层的依赖方都可能发生变化需要重新测试。

在命名和包结构上领域模型不需要带

一样即可但考虑到这是在软件的最内层可能会被所有模块依赖到所以要尽可能贴近其设计目标并且不能太过宽泛。

在包结构上需要被存放在

model

层也比较纯粹只负责简单的数据转换而且对外暴漏的函数都是幂等函数。

UseCase

应当隐藏具体的实现细节不仅包括获取方式是网络还是本地数据也应该隐藏对应的实体数据类这意味着

**Repo

层对外暴漏的函数的入参和出参不能包含接口返回的实体类也不应该包含数据库表实体类只能包含领域模型或者基本类型。

**我们给

Room

{retrofit.create(UserService::class.java)}suspend

fun

userService.getUserInfo(id).let(userEntityAdapter::toUser)}

Repo

请求来说可能会存在一个请求实体这个实体数据类最好也不要对外暴漏可以在

Repo

层还有一个作用就是负责把从接口或者数据库中出来的不友好的数据模型转换成友好的数据模型。

BFF

的存在在某些比较简单的业务场景下我们可以为了方便做一些妥协也就是接口的响应数据实体类可以穿透

Repo

使用但应该明白这只是为了方便的妥协并不是最佳实践需要严格控制影响范围。

UseCase用例

一般是指特定应用场景下的业务逻辑用例引导了数据在模型之间的输入输出并且指挥着业务实体利用其中的关键业务逻辑来实现用例的设计目标。

因此一个

往往只包含一段具体的业务逻辑他的输入是基本类型或者领域模型输出也是并且是幂等函数也就是纯函数所以

Google

最好还是不要直接使用函数来实现应当按照上面的方式定义一个类然后再暴露一个通过操作符重载的函数。

在使用

需要一个有效的手段来进行管理首先应当按功能对他们的包名进行划分。

同一个业务的

UseCase

的极端情况中很多时候我们可以将一些极度类似的功能组织在一个类中其中提供多个公开的方法这样的写法在以前很常见比如各种

Manager,

一定是不可变类如果希望更改其中的某个值应当重新创建一个对象直接通过

data

设计的例如对于一个需要显示的格式化后的时间格式化的逻辑最好放在

ViewModel

整洁架构中的一些关键概念的介绍我已经按照这个架构开发了一年多了目前看下来确实会让架构很整洁但对于一些复杂的业务场景尤其是可能需要穿透多个层级跨越常规生命周期的模块就需要更精细的设计了。