去年 10 月至今，自己参与了大量内部运营活动管理系统的开发工作，大约到今年2月份的时候，在前任小组长的引导下，自己在新模块的开发中尝试使用 TypeScript 开发。
不试不知道，一试才觉得，真香~~
当年在猫眼用 React 的时候，自己开发过大量的使用了表单的系统，那时候就借助于面向对象的技术封装了很多类，来抽象一些数据结构，当时感觉这样做使得代码很清晰。最近基于 TS 开发的项目，复杂度比当时猫眼的要高更多，TS 提供的静态类型系统可以说提供了很大的帮助。
这篇文章就简单对类型系统、领域模型在前端开发过程中起到的作用，进行总结与思考。
前端面临的挑战
首先要讲讲前端面临的哪些挑战，导致我们必须去思考借助领域模型来降低前端开发中的复杂度。
在现代前端十几年的发展历程中，前端开发人员的定位通常以还原交互视觉、提供视图组件解决方案为主，而后端则通常以业务模型、领域模型等作为自己的聚焦核心。前后端之间以 HTTP 或者 Apache Thrift 这些 RPC 技术进行数据通信，相互之间通常不存在很强的静态代码层面的数据结构约束。
但是渐渐的，业务模型越来越复杂，后端的 Model 越发庞大。前端开发者会发现，如果对于后端接口返回的 Model 没有业务上的理解，那么对整个系统进行迭代、重构甚至简单维护，都寸步难行。
软件系统在经历数量级的巨大变化之后，原有的解决方案通常不堪重负。前端必须有个单独的层来对接后端复杂度的巨大变化。
每个开发人员在进入一个新团队时，一般都会给自己设定较为充足的时间来“了解、熟悉业务”，熟悉了业务之后，开发速度也会明显加快。这个业务，本质上是知识，是概念与逻辑的集合，理论上，也是可以用数据结构来描述的。
我所理解的前端需要的领域模型，就是要找到合适的方法来描述解决这几个基本问题：
- 前端开发人员看到的每个字段、属性，是什么
- 业务系统中每个模型、对象，有什么方法/逻辑
- 模型与模型直接的关系，是什么
阶段1：良好的注释与文档
阶段2：面向对象
阶段3：TypeScript
TypeScript 给前端开发人员提供了编码阶段降低代码复杂度、提升代码可读性的极佳解决方案，主要就是因为提供了完备的类型系统。
此外，TS 的强制类型检查，也能帮助开发者在编码阶段提前规避很多问题，例如类型错误、参数个数错误等。