前言
最近花时间看了google 的Jetpack 架构组件，kotlin协程、flow。接着了google官方推荐应用架构指南，compose等。这些是目前主流应用开发采用的技术栈。我们项目中也照猫画虎已经搭建起来了，但是自己理解的很浅，使用官网推荐的架构写起来心里总觉的没有使用MVP 写起来直来直去。但是这些才是未来应该掌握的技术栈，记录下疑惑的地方。
1.标准数据驱动代码样式（MVI架构），和各个层的职责，各层之间如何进行关联。
UI层
Activity、Fragment中是否只放ui相关代码： ui相关代码指的是那些代码?
是否是元素的显示隐藏，添加和移除。字体色值，图片样式，字体大小，是否正在刷新这些只和View 本身属性有关系的元素。
答： ui界面层的代码不包含任何业务逻辑，只放入操作ui显示隐藏，弹窗Toaster 等与ui渲染相关的代码，具体ui界面层使用到的数据，通过观察Livedata或者Flow等状态容器获取来自数据层的数据。而且要保证单一数据源。
viewModel 放入什么代码？起什么作用。
比方说，登录界面中的 [条件检查逻辑],EditerText的 textChange逻辑，检查密码是否符合这样的判断逻辑也放进去吗？viewModel 中需要给界面暴露方法，这些方法是否需要suspend 修饰。
答:viewModel中对ui界面（Activity、Fragment）暴露的方法，不必使用suspend来修饰，使用suspend修饰的函数内一般会做一些耗时操作，而耗时操作通常放在数据层进行处理。 比如：登录界面中关于账户验证和密码验证的逻辑，是放入ui界面还是需要放入viewModel中，建议放入ViewModel中，或者抽离出来放入一个object class xxxManager{ }管理类中。而对于textchange监听的代码，目前还是放在ui中，这个后续会根据理解深浅来确定是否需要移动到其他地方。
网域层 （xxxUserCase）
网域层放入什么类型代码，是否需要suspend修饰。对外暴漏什么样式代码。 网域层可以创建object class 单例类吗？
答：网域层作为viewModel和Repository 中间层，主要目的用来将几个不同的数据仓库聚合在一起。对需要同时操作多个xxxRepository仓库的业务，比较适合。原则上依赖链路为ViewModel - > xxxUserCase -> xxRepository->xxxDataSource .各层之间使用接口进行相互联系。达到解耦目的。
xxxxRespository 存储库
存储库拆分，如何理解存储库拆分，怎么拆分才是正确或者相对正确的。
目前理解，存储库可以根据业务来拆分，loginRespository，RegisterRespository,GameRespositoryd 等，如果是数据库表也可以将一个Respository库对应一个数据表。拿Room数据库为例，一个Dao对应一个Respository。
xxDataSource 数据源
数据源在应用中只有，文件，数据库，内存，网络这些。 如果前期把这些定义了， 也就是全局就这四种数据源。 是否就应该这么定义？
NetDataSource ，DbDataSource ,FileDataSource DataStoreDataSource ，那么一个大型项目只定义这四种数据元，肯定是不够的，如何细分下去？
答：暂时定义四个大型的数据源 ，目前来说比较紧凑，肯定需要进行细分拆解到不同的资源库（xxxxResp），数据源的定义官方也没有给出标准，定义多少更具应用的复杂度不同，酌情增加减少。 比方说，app业务中包含IM聊天和网络请求，本地数据存储这些。可以定义一个
Retrofit请求接口的 NetRequestDataSource, IMDataSource，LocalDataSource等，用来对不同的业务进行隔离。
这是大面上来讲。
工具库，widget 自定义布局，元素 ， 通用网络请求逻辑，拆到那里？
还有协程用法，也是一知半解。 协程嵌套用法， 使用协程发起的网络请求和普通网络请求之间怎么控制时序，那个先执行后执行另一个。并行执行，嵌套写法。
如果在一个全局作用域，创建的协程内调用时序和写的顺序是一致，原因就是协程可以挂起执行，在获取到执行结果后会返回到挂起点，执行后续的步骤。协程声称，同步写法实现异步功能，也是协程可以立足的一个亮点。关于协程的挂起和恢复，建议翻墙看官方文档，一点点的来理解。
自己照葫芦画瓢写的协程嵌套代码，自己写起来就费劲，感觉越写越没底。主要是网络请求代码嵌套看起来并不优雅也不美观。
看了官方的代码demo，使用flow进行数据通知观察，自己照葫芦画瓢依然懵懂，好在团队中都在学习。相信一两个迭代之后，会清除这里定义的
对于协程和flow用法需要放入日常开发中进行体验，协程相对来说理解起来比Flow要好理解。
如何理解业务逻辑
功能逻辑：详细讲解该功能的逻辑。
交互逻辑：对页面之间的相互跳转进行说明。
视觉逻辑：对颜色，对图标的要求。
业务逻辑：讲一下该功能对应着什么业务。
业务逻辑被拆分成实现具体功能函数，不同函数处理不同的问题（输入数据格式校验，格式检查）
1.什么是业务逻辑
