MVC架构缺陷
MVC的架构足以解决前端多数架构场景，但MVC只能解决单模块自闭合场景，如果一个MVC模块内部不断膨胀拆出多个相互关联的MVC模块，形成的网状结构，就远远超出了MVC的能力范围了。
在前端可视化领域，渲染层的交互可能会相当复杂。
比如我目前项目中的echarts图表，有图表组控制，自定义图形创建的十字/单/双游标和气泡mark控制，曲线样式控制，其上游数据还有复杂的二次采样和等比二次缩放；交互有图表组的拖拽合并分列；曲线的拖拽组合；游标的拖拽等等，早期的MVC架构渐渐无力，形成一堆理不清的线团，谁也不知道一个简单的缩放操作会影响到哪些地方。
最终我将MVC替换为了DDD架构。
DDD设计
之前的MVC架构主要从echarts视角触发，而DDD则从整个业务流程出发，因此将核心逻辑分为了以下几个领域：
领域之间以少量事件通信,重点关注领域内部事件。
比如曲线域有大量model entity以及各自service，以及多model之间的各种交互事件，而曲线域和数据域的交互仅通过两个事件。
项目关键技术设计
为了实现上面的设计思路，我们在基础设施上进行了大量的补充，其中比较重要的有：
- 事件中心的设计
- Channel-Distributor模式，让websocket client只进行无脑收发，将ws订阅和分发逻辑完全关在消息域
- IOC容器解决多实例不同scope的创建销毁juejin.cn/post/754384...
- 引用计数，由于存在千万级以上数据，因此当不再有任何一个chart需要消费原始数据时立即清理数据缓存
技术收获
项目中最核心最复杂的业务逻辑全部集中到DDD架构的Core模块，该模块逻辑能够自闭环+独立运行，对其他前端页面来说，可以不再关注这里面的复杂度，仅调用CoreApplication提供的一些事件和方法即可。
另外我们整理了Core模块的领域图，可以一目了然看清领域间事件和领域内事件，能够清晰定位要改动的模块或要复用/增加的关系。
三个月后的技术架构反思
经过一段时间的维护，再来看这个架构，类比后端真正业务上的DDD架构要解决的业务问题，能够看到一些端倪：整个设计被DDD范式裹挟 ，而真正起作用的仅是事件驱动。
| DDD 设施 | 实际角色 | 说明 |
|---|---|---|
| Entity (Chart, Line) | ECharts 配置项的薄包装 | 不是有业务规则和不变量保护的领域实体 |
| Aggregate (ChartGroup) | 一组图表的引用集合 | 没有跨聚合一致性问题需要保护 |
| Repository (TaskDataRepo) | IndexedDB 的 Dexie 封装 | 不是领域模型和持久化的桥接 |
| IoC 容器 | new 的替代品 |
Transient 作用域的 Service 用 new 创建反而更直观 |
| EntityServiceGuard | 解决 IoC 不能级联创建 Service 的 workaround | 本质是框架局限性的补救措施 |
DDD解决的问题是业务规则和建模，这些在前端领域并不是核心问题。这整套架构设计，虽然理清了关系，但部分场景延长了调用链路，导致出了问题调试非常困难，往往要对照架构图理清流程。
如果让我回到过去再进行一次决策，可能用CQRS模式更简单些。用轻量级的事件总线+不同的读写模型+Saga协调跨读写边界，全链路关注的负担会明显减少。