我们的目标是面向社区将 Rexd 打造为更加灵活可用的多端设计体系，在设计侧建立更加灵活可用的设计规则配置能力和配套的设计工具，在技术侧提供更加可用健壮的基础组件体系，为有多端开发需求的中后台业务场景提供低成本的移动化能力。

“怎么不回我消息”“我去输液了”“输的什么液”“想你的每一夜～”

聚合模式是 DDD 的模式结构中较为难于理解的一个，也是 DDD 学习曲线中的一个关键障碍。合理地设计聚合，能清晰地表述业务一致性，也更容易带来清晰的实现，设计不合理的聚合，甚至在设计中没有聚合的概念，则相反。

聚合的概念并不复杂。本文希望能回到聚合的本质，对聚合的定义和实操给出一些有价值的建议。

本文通过介绍词法语法分析器技术和业界的做法，以及过去使用自动生成的词法语法分析器遇到的问题，分享自研SQL Parser的设计与实践，以及其带来的性能和功能的提升。

利用缓存做性能优化的案例非常多，从基础的操作系统到数据库、分布式缓存、本地缓存等。它们表现形式各异，却有着共同的朴素的本质：弥补CPU的高算力和IO的慢读写之间巨大的鸿沟。

和架构选型类似，每引入一个组件，都会导致复杂度的上升。以缓存为例，它带来性能提升的同时，也带来一些问题，需要开发者设计和权衡。

想要搞清楚不同色彩所带来的效果，我们首先需要了解人是如何如何捕捉和感知不同颜色的，本篇文章将带您深入理解色彩体系。

闲鱼作为一个自由的商品和内容分发市场，每天有上百万的用户图片上传，其中不乏图片重复，图片描述内容不明确、图文不符等低质量的商品；也有各种搞笑、抖机灵等倒流的内容；还有色情、黑产等违规或违法灰色地带。如果让这些低质的商品和内容都正常流入每天日常的商品展示中，不但会影响用户的交易效率，还会降低产品在市场中的口碑和价值，甚至增加被监管治理和叫停的风险。

闲鱼是一个以C2C为主的平台，区别于B端的用户，C端卖家在发布商品时更倾向于图+描述的轻发布模式，对于补充商品的结构化信息往往执行力和专业程度都不高，这为我们的商品理解带来了很大的困难。为了能够在发布侧获得更多的商品结构化信息，我们开始尝试在原有图+文的极简发布模式中加入商品关键属性的补充选项，事实证明，适当的结构化属性选项并不会影响用户的发布体验，却能极大地提升我们对商品理解的能力。然而存在以下问题：

在设定结构化属性选项时，往往强依赖行业运营的经验，缺少实时的、多维度的数据分析手段。虽然离线产出的数据报表能够在一定程度上统计某些关键指标，但对于精细的、个性化的数据查询需求，离线报表扩展性和性能都不足。

在日常编码的过程中，我们可以总结出很多“样板代码”，就像”活字印刷术中的“活字”一样。当我们编写新的代码时，需要用到这些“活字”，就把“样板代码”拷贝过来，修改替换一下就可以了，写起代码来“极为神速”。“样板代码”其实就是一种样例、一种模式、一种经验……总结的“样板代码”越多，编写代码的格式越规范、质量越高、速度越快。

Fluent MyBatis已开源。

随着项目功能增多以及规模增大，单体架构的缺点也随之显现，而微服务拆分即可解决这些问题。

到底什么是一个成熟的商业组织想要的结果呢? 那应该是一个健康的可以持续的，因为我们给客户带来利益并给予客户良好的服务体验之后带来的对我们当下组织商业变现的利益反哺。把体验和带给客户的利益前提放在前面，我们来谈谈怎么样去拿结果。

Flutter页面无法直接使用Native测试工具定位元素，给自动化测试带来很多不便。虽然Google官方推出了Flutter driver 和 Integration test，但是在实际使用中存在以下问题：

• 不适用于混合栈APP，虽然appium中有相关的driver，但是无法切换环境。
• 元素定位能力相对薄弱。
• 依赖于VMService，需要构建Profile或Debug包。

基于以上因素，我们并没有直接使用Google官方推出的工具，而是选择基于Native测试工具去扩展Flutter页面的测试能力。本文对Flutter driver 和Integration test的原理和实现进行了分析，同时简单介绍闲鱼在UI自动化测试的尝试方案。

在很多产品中都存在生命周期相关的设计，时间节点到了之后需要做对应的事情。

超时中心（TimeOutCenter，TOC）负责存储和调度生命周期节点上面的超时任务，当超时任务设置的超时时间到期后，超时中心需要立即调度处理这些超时任务。对于一些需要低延迟的超时场景，超时中心调度延迟会给产品带来不可估量的影响。

因此本文提出一种低延迟的超时中心实现方式，首先介绍传统的超时中心的实现方案，以及传统方案中的缺点，然后介绍低延迟的方案，说明如何解决传统方案中的延迟问题。

互联网后端技术的过去、现在及将来

淘宝承接页，如何在兼顾业务需求的同时，做到秒开页面？