虽然公司内的存储和数据系统名目繁多，但一般难以满足领域(就是 DDD 里说的那个
domain)内或子域(subdomain)内的所有需求，在业务部门内部还有着花样繁多的各种数据系统。这样的现状会导致业务接入数据服务的开发成本非常高。
这么说可能比较抽象，举个例子，如果你们公司有 LBS 相关的业务，一般一定会有一个坐标相关的服务，可以使用用户 id 获取瞬时坐标信息。也可能用一个订单或者配送
id 获得某件事情的发生轨迹。坐标轨迹相关的服务和地图类的数据强相关，所以这种服务一般是由单独的部门提供。
再比如说，公司内有公共的订单服务，但主服务不可能为各种相对独立的支撑域(supporting
domain)的业务需求，无穷无尽地加字段，这种时候一般支持域会在其内部构建自己业务强相关的业务数据服务。
Week 2 的问题是 map reduce
优化，说实话，这周的示例代码写的不怎么样，不知道为什么都是同一个人的代码，同一个参数的名字还换来换去，读起来会浪费一些时间。一些缩写也让人比较困惑，比如
fs，bs，别人要稍微思考一下才能看懂这是什么东西，用 fileList 或者 bufferList 显然更好啊，可能样例代码的人是写 acm
出身，比较喜欢赶时间。虽然 Go 的 runtime 代码里也经常这么干，汗。
吐槽就到这里。题目是想让你先把
第一周是给定了函数签名实现多路归并排序。这里
[https://github.com/pingcap/talent-plan/tree/master/tidb/mergesort]。
为啥要考这个问题呢？个人认为多路归并在分布式数据库、分布式搜索引擎领域是挺常见的算法。用我相对熟悉的 es 来举例，在搜索数据时，我们会指定 bool
表达式来对数据进行筛选，同时需要指定每个查询 sort by 字段以及 size，但分布式环境下，我们没有办法确定这 size 个元素要在每个 shard
里取几个元素。所以最基本的思路：
知乎上有一个问题，有哪些优秀的 Go
面试题，其中有一个高赞答案很[敏感词]，从大多数问题上可以看出作者想要问别人什么，对其它应聘者的要求是对常见的性能指标要敏感。
不过我觉得，即使是做优化，很多时候也应该是去做整体优化，而不是在所有地方全部抠细节，那我们程序全用汇编+优化指令写得了。
当然这么说也很空洞，我简单整理一下这些问题的答案，可能其中有些疏漏，如果读到这篇文章的你在某些问题的答案上有不同的见解，欢迎在评论里讨论和补充~
1. 1.9/1.10中，time.Now()返回的是什么时间？这样做的决定因素是什么?
是想考 monotonic time 和 wall
架构师们常讲的设计定律之中最为重要的是康威定律，康威定律的定义：
> Conway's law is an adage named after computer programmer Melvin Conway, who
introduced the idea in 1967. It states that. organizations which design systems
... are constrained to produce designs which are
