本文基于 Java Jetpack MVVM 背景。如您正在使用 Java，通过本文可快速了解 2017~2021 官方架构设计在 Java 语境下存在的弊病及改善建议。
上期《言简意赅 Android 架构设计与挑选》侧重介绍 “表现层” 框架演化历程及选型依据，
而本人对官方架构示例 “ViewModel LiveData 部分” 一向存疑，
故这期我们以 “领域层” 为例，拆解官方设计误区，并给出改善建议，相信阅读后你会豁然开朗。
弊病 1 之 “违背原则之原则”据 wiki 百科介绍，“最佳实践” 乃管理学概念，意即 “认为存在某种技术、方法、过程、活动或机制可使生产或管理实践的结果达到最优，并减少出错的可能性”，
故易知，架构模式即 “软件工程” 领域 “最佳实践”。
软件工程最佳实践有其原则，即 “设计模式 6 大原则”。然如说哪个原则是 6 原则之首、宁违背其他原则，亦不可违背此原则 —— 此即 “单一职责原则”。
单一职责原则与 “本质” 直接挂钩，架构模式设计如违背单一职责原则，是后续所有弊病祸根所在。如这么说无体会，那就继续往下，一睹为快~
弊病 2 之 “ViewModel 职责混杂”Jetpack ViewModel 本质有二，
一是页面状态容器，使页面旋屏重建后可直接从 ViewModel 拿取数据，免去传统 onSaveInstanceState、onRestoreInstanceState 之苦，
二是生命周期作用域可设定之容器，例如作用域设定为 Activity 级，则 Activity 旗下 Fragments 皆可共享 Activity 级 ViewModel 之公共数据。
由此易得，该框架违背单一职责原则。
但其实，这俩功能都有存在意义。那怎办，此时最佳实践即，通过创建子类，继续划分职责，直至各司其职即可，
例如可将 ViewModel 划分为 State-Holder 和 Event-Handler，
前者专职托管页面状态数据，是表现层组件，可作为静态内部类声明于 Activity/Fragment 中，作用域仅限该页面本身，为该页面专属；
后者专职业务逻辑处理及结果统一分发，是领域层组件，可为多个 Activity/Fragment 复用。
也因此，State-Holder 为 “表现层” 缓存，Event-Handler 为 “领域层” 唯一可信源，数据来去之流程，总是从页面发起 Event，交由 Event-Handler 处理并回传 Event-Result 至页面。页面 States 根据 Result 完成赋值，控件亦根据 States 完成渲染。
由此，当页面旋屏重建时，表现层仍是从 State-Holder 读取缓存完成渲染，而领域层 Event-Handler 在完成自己那一环推送后，不应越界干涉、自动重推（replay），以免好心办坏事。
—— 正常流程就该是这样。
弊病 3 之 “生搬硬套”现实中，领域层高频痛点是 “消息分发可靠一致” 问题，本质是领域层无唯一可信源。找准该痛点，点到为止精准治理即可。
反之如 “响应式编程” 一刀切，违背单一职责原则，则易埋下祸根。LiveData 粘性设计便属其一。
LiveData 系借鉴 ReactiveX BehaviorSubject 设计 —— 作为 State 容器，总是有值，当订阅者订阅时，自动回推最新一值，否则自动回推默认值。
然 ReactiveX 属 “理想化” 过度设计，现实中除 Jetpack Compose 及我们开源的 DataBinding “严格模式”，99% Android 程序皆 “命令式思维” 而非 “函数式思维” 书写 GUI 管理 —— “响应式编程” 在 Android 下不似 Web 前端相得益彰，而需人为刻意维持，如此该架构十分脆弱，稍有松懈，便易滋生不可预期问题。
—— 如无必要，勿增实体。架构模式应致力消除 “不可预期问题”，而非逆行倒施。
弊病 4 之 “LiveData 粘性设定”不可预期问题 1：
响应式编程使 Java 页面需特意增设各式 RequestState 方法，宛如当年 MVP 接口爆炸，
且只要开发者稍一松懈，便易在页面中定义 States。而根据粘性设定，旋屏重建会收到 Event-Result 推送，该数据相较 States 反是过时信息，造成旋屏前后页面状态不一致
也即造成事实上 “表现层有两个 State 来源”。
不可预期问题 2：
现实中常有 “横跨一至多级页面通信” 需求，非 Result API 易胜任。鉴于 LiveData 生命周期安全设计，其配合 Application 级作用域 ViewModel 本可视作页面通信首选。然粘性设定使 “重进二级以上页面” 时收到不可预期旧数据推送。
—— 单向数据流旨在 “总是向观察者提供最新可靠一致数据”，根据上述两例可见，粘性设定恰好取得相反结果。
弊病 5 之 “更迭迟缓”此弊病乃弊病 1、2、3 蒙蔽所致。职责混杂 ViewModel 使其架构看似 “三层”，实则 2.5 层，ViewModel 既属表现层，又属领域层，
虽经 4 年摸索，于 2021 年底正式引入 domain，确立 ui、domain、data 三层，然未见从根本上拆解 ViewModel 等框架职责，此乃原罪。
至此易得，官方在 ViewModel 使用乃至 LiveData 设计存在误区，故我们祭出解决方案 UnPeek-LiveData，由此问题便也仅剩消除 mutable 样板代码。
使用 MVI-Dispatcher 承担 Event-HandlerMVI 架构模式是一种局部改进，可用于集中管理 “Event 接收及 Event-Result 分发”，以消除 mutable 样板代码。
如用 Kotlin，有 Flow 和 sealed class 加持，水到渠成，
然根据现实情况，多数公司 “远古巨型项目” 仍需 Java 升级维护，且 Java 恰是一致性问题频发大户，亟待 “架构组件” 助力规避隐患。
故 Java 实践 MVI 过程中易体会，由于事件皆交由一个 UnPeekLiveData 分发，而 LiveData 内部无队列设计，连续发送几个事件，只保留最后一事件，MVI 难维继。
MVI-Dispatcher 应运而生。
1.遵循 “单一职责原则”：MVI-Dispatcher 仅用于承担上文所述 Event-Handler 职责，消除只读 Result 分发模型中 mutable 样板代码，故可无缝整合至 Jetpack MVVM 等模式项目。
2.遵循 “迪米特原则/最小知道原则”：通过 “内聚” 设计，将 LiveData 屏蔽，故开发者只可于 Dispatcher 内部通过 sendResult 回推消息，杜绝 Activity/Fragment 误用滥用 setValue，确保消息来源一致性。
且其简明易懂 input - output 设计，使开发者只需关注 input、output 这两处，从唯一入口 input 处注入 Event，并在唯一出口 output 处观察 Event-Result。
3.引入队列设计
MVI-Dispatcher 通过 Event-Result 定长队列支持事件连发，
Event-Result 随取随用，用完即走，无内存溢出隐患，且绝不丢失事件，
具体可根据 ComplexRequest 等案例测试，观测 Logcat 实际输出。
Github: MVI-Dispatcher
Github: MVI-Dispatcher-KTX（for Kotlin only）
最后天下本就无完美事物，有则是创作者精益求精、各路贤人能者集思广益。
UnPeek-LiveData 等框架经 QQ 音乐等月活过亿平台历练，现版本号已转正；
MVI-Dispatcher 尚处公测阶段，欢迎各位大佬测试反馈。
,
