关于业务组件交互方式抽象的合理性 #5
Description
目前业务组件之间的交互抽象出来了三种方式 ：
- 路由 ： 界面相关的调用
- 数据 ： 公共数据的共享。
- 事件 ： 统一的事件通知体系。
而我们在未来的计划中还要添加一种新的交互方式， 称为
- 服务 ： 一种异步、支持一对多的数据请求方式： 主要解决业务组件可能需要获取其他业务组件中的数据的情况。举例： 搜索页面 可能需要获取 账单、商品、消息等组件中的搜索结果。
基于以上4种交互方式，我们要探讨其合理性，即是否可以去除掉某种交互方式或者进行合并。
路由： 可读性
路由是界面跳转和展示的基础交互方式，虽然可以通过事件或服务的方式进行调用，但是这样就导致代码可读性较差。 所以为了使API更加合理，提高代码可读性，路由模块肯定是要保存的。
数据： 解耦
数据或者称为公共数据区，主要负责管理和存放公共的数据。 而公共数据的必要性，取决于一些公共数据可能由多个业务组件共同管理。 如以账号信息为例， 操作账号信息的组件可能为 登录组件和个人信息组件 ： 登录组件进行登录，填入账号信息；个人信息组件进行登出和修改。所以如果没有公共数据区，在这种业务需求下：我们无法将登录信息单独放到 登录模块， 放在登录模块意味着为个人信息模块提供接口来修改登录模块的内容，这样过于耦合，交互上不合理； 我们只能将公共信息下沉，即将这里的账号信息放到基础业务库中，由两个组件共同依赖， 但这样的下沉会逐渐堆积，导致基础业务库过于臃肿。
所以，使用公共数据区，来解决这种多业务组件共同读写数据的依赖，是有必要的。
服务： 业务需要
业务需要异步请求数据的接口， 需要一对多的数据获取接口。
而对于服务的定义的存放位置，目前我们认为应该下沉到公共区。 首先服务的实现者，可能是多个业务组件，所以不可能将服务接口放在实现方。 其次：放到调用方，就会导致服务的实现者依赖调用者，导致依赖逻辑混乱（目前我们仍然想要保持依赖逻辑的清晰合理）。 所以只能将接口下沉到公共区： 但必须防止公共区臃肿的问题。
事件： 依赖层级
事件通知也有使用服务进行调用的可能性， 相当于一个不需要结果的服务调用。
事件与服务分离，可以从层级去分析。 举例如一个商品组件，一个登录组件，商品页面需要在登录完成时展示一些内容，即需要登录的通知。如果使用服务来实现，按照目前的服务逻辑，接口就要下沉到公共区； 但是事件通知应该是依赖关系的，即商品组件依赖登录组件的。 所以，强行使用服务来替代事件，会导致依赖关系不清晰，且导致公共业务区臃肿。