日历原为单体架构，存在“循环日程”数据模型平铺导致的数据膨胀（单表数
据量过亿）、日历模型扩展性不够，日程与会议室资源强耦合等问题，导致维护
成本高、查询性能差。
核心挑战与行动：
1. DDD 领域重构：主导系统重构，重新划分业务边界。将原来的单体应用拆分为三个
服务，A 作为代理服务，负责与 Exchange 的交互细节；B 作为领域核心服
务，负责日历的管理、日程的管理、参与人的管理等，只关注领域事件；C 作为前
台服务，是比较薄的一层，负责三方业务对接以及协议转换等。
2. 会议室系统与日程系统解耦：由于历史原因，会议室和日程是同一个团队维护，两
个系统间交互很不合理。识别“日程”与“会议室”为独立聚合根，将会议室资源管理从日历服
务中剥离，对于属于会议室领域的功能和数据从大象日历拆除，解决了强耦合的痛点。
3. 存储模型优化：针对“循环日程”数据膨胀问题，设计基于 RRule（递归规则） 的新
型存储模型，替代旧的平铺存储方式，大幅降低数据库存储压力。到目前为止，老表的数据
量将近 1 亿，新表数据在 3000 万左右。
4. 平滑迁移方案：设计“双写 + 异步校验 + 灰度切流”的数据迁移方案，在业务无感
知的前提下，完成了海量日程数据的底层模型切换。