关于 Clean Architecture 和 MVP 的一些想法简要总结

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

原文发表于WahibHaq博客。

大约三个月前，我正在找一份安卓开发工程师的工作，经历了各种面试环节。其中一位潜在雇主给了我一个任务，要求我针对以下情况提交一份一页纸的架构建议：

You are an experienced developer. Can you design 1-page architecture of an app
for a financial product with 50k users base (3k daily), that can work in a
modern setup of development, e.g. Spotify squads? Once you come onboard you may have to design for 10-100x userbase. The architecture can be a generic view.

我研究并整理了自己的想法，写成了一份文档。今天，我决定把它发布成一篇博客文章。

免责声明：本文并未提供对Clean Architecture或MVP的详细解释，而只是重点介绍所提出的解决方案并概述我的理由。

顺便提一下，2017 年我对Clean Architecture产生了兴趣，并在Freeletics的 Android 应用中实践了Model-View-Presenter (MVP)架构模式。总的来说，软件架构一直是我感兴趣的领域，但遗憾的是，我之前从未有机会在任何一个 Android 项目中应用它。Android 开发者都明白，如果没有可靠的架构，构建健壮、高质量、易于维护的应用是多么困难。

有趣的是，2017 年将永远被铭记为谷歌首次正式推荐Android 应用架构的一年，该架构采用了架构组件（Architecture Components）。架构组件本质上是一系列库的集合，旨在提供简单、灵活且实用的方法，帮助开发者摆脱一些常见问题，从而专注于编写模块化应用，减少样板代码，打造卓越的用户体验。

现代应用程序架构应该具备哪些特点？

我认为，它需要具备以下特点：功能强大、稳定可靠、易于扩展（只需付出最小的努力）、能够根据敏捷需求进行调整、能够快速集成新的平台功能、支持可测试性，同时还要便于不同级别的开发人员理解，以确保可维护性。

我认为“整洁架构”是解决之道。

清洁建筑

                                          来源：8thlight.com

在整洁架构中，代码被分层，呈洋葱状，并遵循一条依赖规则：内层不应了解外层的任何信息。内层包含业务逻辑，外层包含实现，中间层包含接口适配器。每一层代表一个抽象层次。

Some key technical benefits achieved in this way are:

> Abstraction over Implementation
> Single Responsibility Principle 
> Separation of Concern
> Decoupled Code

不同的层、组件以及它们之间的通信方式

                                                                            来源：five.agency

表示层/用户界面层

• MVP模式更适合用于用户界面/展示层。
• 视图是哑的，并实现了被动视图模式。它是一组接口，任何 Android 视图都可以实现这些接口，例如 Activity、Fragment、Adapter 或自定义视图。
• Presenter 作为视图（Android 特定组件的抽象层）和业务逻辑（交互器/用例）之间的中间层。它们处理用户交互，调用相应的业务逻辑，并将数据发送到 UI 进行渲染。
• Presenter 不依赖于 Android 类，因此提高了可测试性。

领域层

• 一个简单的用例示例是“将资金从一个账户转账到另一个账户”。每个用例都是一个可重用的组件，用于执行特定的业务逻辑。它从存储库中获取数据，执行业务逻辑，并将结果返回给表示器。

数据层（数据库和API）

• 仓库模式负责创建数据源的抽象层，用例从中获取数据并执行相应的操作。所有底层持久化工作都应该在这里完成：数据访问对象（DAO）、对象关系映射（ORM）组件、Retrofit（或其他任何网络相关组件）服务、JSON 解析等等。
• 即使在网络不稳定的情况下，应用程序也应该流畅运行。缓存和重用先前获取的资源是优化性能的关键所在。
• 业务逻辑不应该知道数据来源。本地执行，全球同步。

设备层

• 设备包含 Android 底层功能的实现，例如传感器、警报器、通知、播放器、各种管理器等等。

拟议架构分析

• 遵循清洁架构。
• 所有功能都按模块级别、包级别和类级别进行了清晰的划分。因此，单一职责原则和关注点分离原则应该都能得到满足。
• 业务逻辑不再直接接触 Android 系统，这将导致代码库解耦。
• 通过将相应依赖项的模拟实现注入到不同的类中，可以大大简化测试过程。
• 无需强制使用 Presenter 来处理演示逻辑，我们可以说 Clean 架构与“前端”无关——这意味着我们可以在其上使用 MVP、MVVM 或任何其他技术。
• Presenter 依赖于 View 接口，而非直接依赖于 Activity：这样，我们就成功地将 Presenter 与 View 实现解耦，符合SOLID原则中的“解耦”原则。我们可以替换具体的 View，而无需修改 Presenter 的任何代码。此外，我们还可以通过创建模拟 View 轻松地对 Presenter 进行单元测试。
• 每一层都有自己的模型，因此具体的细节（例如视图）并不依赖于底层实现的具体细节。
• 与其使用回调函数在各层之间进行通信，不如利用RxJava的强大功能，将数据提供给上游，并让它负责线程调度。每个内部层都可以将数据转换成外部层能够理解的方式。
• 允许更改任何外部层的实现，而无需对我们的代码库进行大量更改，满足可扩展性要求。
• 这种方法虽然困难且耗时，但可以把它看作是对未来将要使用和维护代码的开发人员的帮助。
• 值得一提的是，这支持使用像Dagger这样的依赖注入框架。

跨职能团队和架构

上述问题陈述中还提到了Spotify Squads，这是一个源自 Spotify 工程文化的非常有趣的概念。产品团队似乎是构建强大且知识渊博的开发团队的绝佳方式。通俗地说，Squad 是一个小型跨职能的自组织 Scrum 团队。他们承担端到端的职责，并共同朝着长期目标努力。Squad 的核心驱动力是自主性。

对于雇主而言，敏捷开发是一项至关重要的要求，因此他们期望架构能够支持敏捷开发。敏捷开发最重要的原则之一是：

“最好的架构、需求和设计都源于自组织团队。”

• 本吉·韦伯认为，团队中并不需要专门的架构师，这是团队的共同责任。在理想的团队中，每位成员都应该思考彼此重叠且互补的问题。
• 软件架构不应该成为 5 到 9 名成员的团队将一个功能从开发到可发布阶段的阻碍。
• 整洁架构通过关注点分离，赋予开发团队所需的节奏和敏捷性，以应对环境中的复杂性和快速变化。它通过设计在组件之间建立界限，同时为未来的沟通奠定基础。这使得 Android 开发人员能够与其他团队的成员和谐协作。
• 在开始开发某个功能之前定义MVP 合约的做法，间接地帮助同一团队中的 Android 开发人员有效地定义彼此之间的职责范围。

延伸阅读

• 所有这些关于“清洁架构”的胡言乱语到底是怎么回事？
• Android架构系列
• 将应用程序转换为使用 Clean Architecture
• 构建 Android 架构……以简洁的方式？
• 清洁架构完全傻瓜指南
• 基于 Android 架构组件的响应式 Clean 架构