IM微服务划分-DDD
设计目标
期望实现IM到基本功能如下：
- 单聊/群聊/聊天室/多设备登陆/在线状态
- 文本消息/多媒体消息/离线同步/历史消息/消息漫游
- 多端同步/消息撤回/已读未读/离线推送
- 添加好友/会话列表/好友列表
评估标准
- 技术角度看
- 整体通信复杂度降低，RPC调用次数可以收敛
- 关键接口满足“延迟，吞吐，可用”等要求指标约束
- 便于快速发现/定位/修复问题的可维护&可观测性
- 业务角度看，实现上述产品功能，面向业务需求可扩展
- 反复同类需求可配置化且自动化，可沉淀到运营&产品平台进行自助解决
- 便于数据分析，提供在线&进线&离线数据的快速且灵活查询
- 坚顾长短期目标，短期敏捷迭代，长期整洁架构
- 管理角度看
- 保证交付需求的质量，上线后不会引入新的问题，达成预期
- 保证需求如期交付，技术人员的需求负载均衡，且高吞吐低延迟的交付需求
- 应对人员流动，每个模块都要有backup，并且保证新人快速接手
- 合理规划技术团队职责，保证协作沟通效率，分离关注点与职责范围
解决方案
事件风暴
命令风暴
聚合以及聚合根
界限上下文
- 拆分用户服务User server，用户管理用户信息与权限
- 拆分关系服务Relation server，用户管理用户关系链和链上的权限信息，数据
- 拆分消息服务Message server，用户管理消息纬度的权限、信息、存储等工作
- 上述三者为领域服务，对外暴露一个应用服务API server，业务适配与需求交付
- 抽象一个common包封装所有基础设施等依赖接口，实现依赖倒置
- 领域层仅依赖接口而非基础设施等具体实现
- 所有服务均使用相同的common包来操作基础设施层
- 只有抽象出领域服务，确定核心域才能形成真正的业务资产
