Meeting Notes 2016.11.9

[Brooooooklyn]

主要存在的问题：

1. API 里面 get 的方法语义不明确
2. Model 中涉及到的业务逻辑太多，没办法抽象
3. 由第二个问题引发的一个后端 API 对应不同的 query 导致业务上需要拆分成 N 个 SDK 的 API:

getMyDueTasks(_userId: UserId, query?: any): Observable<TaskData[]>
getMyTasks(_userId: UserId, query?: any): Observable<TaskData[]>

结论

1. 所有 API 的 get 方法拆分，比如 getMyTasks 拆分成 listenMyTasks + getMyTasks:

这样在开发业务的时候需要区分 listen 语义的调用和 CRUD 语义的调用。 listen 的调用只关注数据，CRUD 的调用只关注状态。

2. Model 中涉及到的业务逻辑全部让调用方从外部传进来（其实目前只涉及到 Collection select Condition)， 然后 SDK 在内部根据 query + select condition 创建不同的 Collection。

3. 由于业务部分的逻辑从 SDK 剥离，那么第三个问题很好解决，一个 API 对应一个后端 API，动态的 query 和 select condition 由外部传入动态生成。

悬而未决的问题

1. Collection 分页的行为还需要进一步确认，最好是在实际的业务场景中确认这个 Pattern 是清晰可行的。
2. Collection 的底层实现 (Subject/Observable) 需要验证。

下一阶段的目标

1. 决定分离 get API 的具体实现细节: 将 get() 变成 listen() + get() 或 get().run() + get().listen()。 由 @xufei @aicest @Brooooooklyn 讨论后决定

2. 抽离 Model 层的业务逻辑: @Brooooooklyn 实现，包括重构测试的任务，预计一个 sprint 内完成。

3. 抽象 query + condition + fetch => API 的过程，最好是做到新加一个 API ，SDK 仅在 API 层加几行代码就能实现。 @Brooooooklyn @xufei 讨论后实施。

下一个 sprint 将继续跟进这三个问题 😈

[Saviio]