在架构师们很喜欢的 Domain Driven Design，即 DDD 中，第一课就是教导团队形成自己独有的通用语言(Ubiquitous
Language)，作为业务概念沉淀下来。
作为非英语母语的国家，我们在日常交流中使用的是中文，在公司业务战略描述上使用的是中文，在高层进行任务拆分的时候使用的是中文，在领导安排工作的时候使用的是中文。唯独到了具体实现，即代码这一环节便变成了英文。当然这里我们不考虑有些公司会有汉语拼音这种尴尬的情况。
两种语言天生便有难以填平的鸿沟，在业务人员编写代码时，从中文到英文的转换，往往丢失一部分业务信息，产生一部分信息噪音，或者发生概念上的偏移。
英文语系的人对业务进行建模时，与业务方(领域专家)交流时，产生的概念和反馈可以直接落实到代码上，他们所使用的词汇不会发生变化。而其它语系的人就会在编写代码的时候发生概念偏移，比如我司是做打车业务，
流式计算系统是近些年发展较快的领域，虽然发展迅速，但实际上直到现在都没有能让所有人都满意的系统出现，哪怕是 flink/blink。
流式计算的理论基石是 leslie lamport 在 1985 年发表的论文《Distributed Snapshots: Determining
Global States of a Distributed System》。首先将分布式系统中的进程定义为 process，然后将进程间的连接定义为
channel。当需要计算全局状态时，因为没有能够全局同步的时钟，所以需要有别的办法能够记录整个计算集群的状态值。
process 及连接 process 的 channel
Gopher China 讲师尘埃落定，可惜今年没有获得去讲的机会，把之前的内容总结在 Blog 里吧~
由于 MySQL 类带 Schema 类存储系统的设计问题，不支持快速的列扩充，实际业务中，一个业务实体的属性随着业务的发展是一定会膨胀的。这样持续在
MySQL 上加列往往就会捉襟见肘。比如我的历史业务订单表有 50 个字段，虽然会对历史数据进行归档，但在线上还是会有千万甚至亿级的数据，这时候在 MySQL
上加列一般使用 PTOSC 或者 Ghost 来改表，两者设计有区别，但缺点都一样：慢。
在公司内见到无数的人在前仆后继地造规则引擎，起因比较简单，drools 之类的东西是 Java 生态的东西，与 Go
血缘不合，商业规则引擎又大多超重量级，从零开始建设的系统使用起来有很高的学习成本。刚好可能也不是很想写 CRUD，几个人一拍即合，所以就又有了造轮子的师出之名。
要造一个规则引擎，说难实际上也不难。程序员们这时候捡起了学生时代的编译原理书，抄起递归下降、 lex/yacc 或者再先进一点的 antlr 之类的
parser generator 就搞了起来。造的时候说不定还发现噢噢，大多数 parser generator
还有不支持左递归的问题，然后按照它支持的文法写出的
2018 已经过去了，在 2018 年中的时候给自己定了 11 个目标：2018 目标 [http://xargin.com/2018-plan/]
，最优先的目标大部分也完成的差不多了，对 Go
源码的阅读工作量稍微有点低估(剩下一些查漏补缺的东西了)。。后来发现有位国外的兄弟也在干类似的事情，不过比我包装的更好：go-under-the-hood
[https://github.com/changkun/go-under-the-hood]。虽有冲动把我的 Go
语言总结也慢慢向这种开源书的形式靠拢，不过想想，好像也没什么特别大的收益，暂时作罢。
18
