新的一期技术雷达如期发布，仔细阅读了这一期的所有条目，CUPID这一条尤其让我产生共鸣。
CUPID出自Daniel的一篇名为《CUPID—for joyful coding》的博文，即《CUPID-为了快乐编程》。CUPID是Composable/Unix philosophy/Predictable/Idiomatic/Domain based几个单词的缩写，有经验的同学一看就知道这是好代码的一些属性。知道Cupid这个单词的同学还能感受到这一组属性所蕴含的对于软件工程的热情。Cupid的中文是丘比特，是指古罗马的爱神，其意象是一个长有翅膀的小孩，拿着弓箭射向人们，以便人们可以相互爱上对方。
前段时间，咱们CTO八叉在极客时间做了一次关于用Smart Domain实现DDD的分享（点击这里回看）。一个新词Smart Domain进入大家的视野。
Smart Domain是啥？为什么可以用Smart Domain实现DDD？本文尝试结合以往对DDD的学习和实践的经验，跟大家分享一下个人的理解。
八叉在分享中提到Smart Domain这个名字来源于Smart UI。我们都知道Smart UI是DDD中提到的一种反模式，只能用于解决简单问题。这里的命名略带反讽戏谑的意味。
前面的文章《我理解的Smart Domain与DDD》中，我们分析了 Smart Domain 的设计，尝试回答了为什么 Smart Domain 可以用于实现 DDD，并对Smart Domain和DDD进行了一些扩展性的讨论。
虽然 Smart Domain 作为一种设计范式，可以辅助我们实现 DDD。但是具体到真实项目中，建模这个过程还得结合实际的领域问题，深入思考，大量尝试，大声建模，才能得到好的模型。有哪些值得参考的案例呢？下面分享几个个人在项目中觉得还不错的建模实践。
在Python的世界里，将一个对象以json格式进行序列化或反序列化一直是一个问题。Python标准库里面提供了json序列化的工具，我们可以简单的用json.dumps来将一个对象序列化。但是这种序列化仅支持python内置的基本类型，对于自定义的类，我们将得到Object of type A is not JSON serializable的错误。
我们每天都在用某种编程语言写代码，但是我们真的了解它们是如何工作的吗？代码是如何转换为计算机可以识别的机器码的呢？
了解编程语言的工作原理，不仅可以让我们深入理解某一种编程语言，某些时候还可以帮助以一种更优雅的方式实现想要的功能。比如我们平时谈论很多的DSL（Domain Specific Language），在定义了DSL之后，我们如何做更进一步的支持呢？事实上我们还可以实现DSL的自动错误检查，还可以将其转化为某种可以执行的程序等等。还比如我们经常遇到的模式识别问题，状态机相关问题等等。对于这些问题，编程语言的实现原理可以给我们很多启示。
随着机器学习的流行，Python近几年的热度一直在上升，再加上Python本身语言设计的简洁直观和易用，Python越来越得到开发者的青睐。但是我们却时常听说Python性能低，不如java，更比不上C。在这些抱怨背后到底是什么原因呢？Python真的性能低下吗？有没有什么优化的办法呢？
对于单纯的复杂计算过程，Python性能是比较低的，这是由于Python本身在设计时首要考虑的是如何快速完成工作（get things done），所以在性能上难免会有一定的牺牲。但是由于python和c有着非常好的互操作性，这类问题都可以通过实现一个c语言的版本来解决。当然从代码编写技巧的角度也有一定的优化空间，如果我们想做极致的性能优化，可以参考官方的性能优化技巧。
中台的概念从阿里17年开始提出来就快速成为了年度IT热词。阿里这样体量的企业的成功无疑论证了中台建设的正确性，让大家对于中台这样的解决方案跃跃欲试。而阿里顺理成章成为了中台的最好代言人，大家学习中台的榜样。那么什么是中台？事实上，对于中台的定义大家也一直在探讨中。阿里内部业务系统有其独有的特点，诞生其中的中台自然也带着阿里独有的特征，这一点从《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书中我们也能读出来。直接复制阿里的中台方案真的能解决广大企业中的共性问题吗？可能未必，这应该也是当前大家关于数据中台有着各种各样的解读的原因。
随着微服务和DDD的兴起，领域这个词逐渐成为了一个大家每天讨论中的高频词。对于经验稍欠缺的同学们，刚接触领域这个词，总会感觉有点神秘。到底什么算是一个领域呢？我们经常在谈论领域模型、领域服务、领域事件、领域边界等等，如果对领域概念没有一个清晰的认识，在接受这些相关概念上想必也会遇到阻碍。本文将结合我个人的理解以及一些实践经验来谈谈对这个概念的理解，希望能帮助大家更好的认识领域，进而更好的理解和运用相关的概念，最终更好的指导软件开发实践。
我时常在项目中听到一些经验稍欠缺的开发人员在Code Review时这么讲：
这里为了方便测试我抽取了一个纯函数，这个函数包含了主要的业务逻辑，测试覆盖率也比较高，我们可以认为这一部分质量不错。
使用这个函数的地方由于集成度高不好测试，我们就不做自动化测试了。
他的代码可能写成下面这样：
1 | // some_file.ts |
在最近的一个客户项目上，为了做性能优化，我们花了大量的时间，然而最终结果还是不够理想。我们的场景是实现特征处理过程和机器学习模型线上推理服务。由于用户量巨大，我们需要做到2万的TPS，每个请求需要在30ms内返回，且每个请求中包括对1000个项目的处理过程。
我们所使用的技术栈是spring和grpc。在经过极致的代码优化及内存调优之后，运行在一台32GB内存64核CPU的服务器上，我们发现90%的请求可以在25ms完成。但是如果观察99%的分位线时，响应时间就下降到了70ms，有时候还可能超过100ms。
为什么会出现上面这么明显的波动呢？问题出在java的gc上。其实对于gc，我们已经非常仔细的做过调优了，整个过程没有full gc的发生。然而，在持续的压力测试下，java的young gc却在频繁的工作。由于处理的数据量过大，新生代的gc几乎每秒都会触发一次，每次释放5GB内存，耗时30ms左后。