统一语言：编程基础

统一语言就是大家都有共识的语言 —— 这不是废话么 —— 其实有些时候还真不是

事情远没有我们想的简单

比如：

• 同一个数据结构在不同的编程语言中可能不同
• 同一种技术实现在不同编程语言甚至不同技术栈下也不同
• 即使语言相通，但是大家都不清楚双方的语言相通，可能会出现怀疑和疑惑，最后造成重复实现或者业务耦合

举个简单的例子 —— IOC

react 下 叫状态逻辑复用 hooks，vue 下叫组合函数 composition，ng 下叫做 service

谁说得对？

其实大家说的都是一个东西，并没有区别，但是如果语言不统一，团队间就无法形成合作

不只是大家用的技术栈不一样，即使技术栈相同，如果开发经历不同，也可能造成语言不一致的情况

比如，大家都用 IOC 实现某个需求

但是 React 程序员喜欢遵从函数式开发的思想，用 reducer 传递 dispatch，而 ng 程序员喜欢组合服务

造成的后果是什么？

react 程序员可能会直接在服务中写下 ：

Rx.reduce((state,reducer))  
action$.next('new action') 

的代码，然后让 ng 程序员看得一头雾水（即便不是一头雾水，也会降低阅读效率）

再比如，React Vue 程序员都习惯组件级别注入，依托组件构建逻辑结构，但是这对 ng 程序员来说完全无法理解 —— 不是说优先通过模块组织功能结构么？

这又有了新的问题，对于 React Vue 程序员来说 —— 什么是模块？

这又会反过来影响 React Vue 程序员，比如 —— 组件中频繁写 Context.Provider / provide()好麻烦

说了一下问题，但是这个问题怎么解决呢？

答案就是，统一语言

我们用统一的语言，描述应用的核心功能，抛弃一切具体实现

我们用提供者（提供商），代替 provider value 代替 provide() 代替 providers:[…]

我们用服务，代替 hooks 代替 composition 代替 service

我们用依赖注入，代替 useContext 代替 inject 代替 constructor(injection)

我们用模块，代替 服务+注入点组件构成的文件夹

我们用分形聚合 aggregation，代替子服务

用值对象，代替全局数据，领域静态数据

用领域事件，代替 dispatch，代替 injected ref 赋值，代替流

这样，我们就能取缔具体技术实现对我们的干扰，并且在团队中能够顺畅交流

这样的语言 ——

不分前后端终端和算法

任何人，只要是程序员，都可以用这套语言进行交流

而这还只是开始

下一步，我们要对业务语言进行约束，提供统一的 ——

限界上下文

领域内为统一语言，而领域外又将命名权限给与其他系统

每个系统内部，语言一致

保证单机内，文件划分符合 LIFT 原则

保证多节点，节点命名空间也符合 LIFT 原则

其实业务开发工作的核心逻辑，并不复杂，不是么？