知鸦日报2021-10-16

“下拉刷新专利由推特拥有，但我想任何人都不用为此担心。-Loren Brichter ”

据说这种交互是前苹果设计师L.B.设计Tweetie应用时缔造的，现在从推特到QQ，下拉刷新已经成为普适的体验，它几乎存在于你手机里的每一个APP中。

架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步，因为一个好的架构能让系统安全、稳定、快速迭代。在一个团队内通过规定一个固定的架构设计，可以让团队内能力参差不齐的同学们都能有一个统一的开发规范，降低沟通成本，提升效率和代码质量。

在做架构设计时，一个好的架构应该需要实现以下几个目标：

• 独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
• 独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
• 独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
• 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
• 可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。

这就好像是建筑中的楼宇，一个好的楼宇，无论内部承载了什么人、有什么样的活动、还是外部有什么风雨，一栋楼都应该屹立不倒，而且可以确保它不会倒。但是今天我们在做业务研发时，更多的会去关注一些宏观的架构，比如SOA架构、微服务架构，而忽略了应用内部的架构设计，很容易导致代码逻辑混乱，很难维护，容易产生bug而且很难发现。今天，我希望能够通过案例的分析和重构，来推演出一套高质量的DDD架构。

对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，还是 03 年的 Enterprise Integration Patterns ，都是通过一系列的设计模式或范例来降低一些常见的复杂度。但是问题在于，这些书的理念是通过技术手段解决技术问题，但并没有从根本上解决业务的问题。所以 03 年 Eric Evans 的 Domain Driven Design 一书，以及后续 Vaughn Vernon 的 Implementing DDD ， Uncle Bob 的 Clean Architecture 等书，真正的从业务的角度出发，为全世界绝大部分做纯业务的开发提供了一整套的架构思路。

这篇文章和《阿里技术专家详解DDD系列 第二弹 - 应用架构》隔了比较久，一方面是工作比较忙，另一方面是在讲Repository之前其实应该先讲Entity（实体）、Aggregate Root（聚合根）、Bounded Context（限界上下文）等概念。但在实际写的过程中，发现单纯讲Entity相关的东西会比较抽象，很难落地。所以本文被推倒重来，从Repository开始入手，先把可以落地的、能形成规范的东西先确定下来，最后再尝试落地Entity。这个当然也是我们可以在日常按照DDD重构时尝试的路径。

提前预告，接下来的一篇文章将覆盖Anti-Corruption Layer（防腐层）的逻辑，但是你会发现跟Repository模式的理念非常接近。等所有周边的东西都覆盖之后，再详细讲Entity也许会变得不那么抽象。

DDD 的宏观理念其实并不难懂，但是如同 REST 一样，DDD 也只是一个设计思想，缺少一套完整的规范，导致DDD新手落地困难。 我之前的架构篇主要从顶层设计往下看，从这一篇开始我希望能填补上一些 DDD 的代码落地规范，帮助同学在日常工作中落地 DDD 思想，并且希望能通过一整套规范，让不同的业务之间的同学能够更快的看懂、掌握对方的代码。但是规则是死的、人是活的，各位同学需要根据自己业务的实际情况去有选择的去落地规范，DDD 的规范不可能覆盖所有场景，但我希望能通过解释，让同学们了解 DDD 背后的一些思考和取舍。

随着各业务流量红利逐渐见顶，如何在有限的流量下，提升流量给用户带来的体验，对流量进行精细化运营，进而提升转化效率，成为各业务的重要课题。

蚂蚁数字金融线包含了 保险/理财/信用/借贷 等业务，经过多年建设，形成了多样的金融资产/场景服务/权益/内容等多维度的产品去服务用户，而这些产品分发给用户时，决定曝转率的大体上以产品推荐是否精准，以及产品以什么样的UI表述方式进行展示决定。在产品推荐上，算法已经逐步覆盖，给业务带来很大的效果提升，在产品推荐算法优化到一定程度后，提升的投入产出比已经有限，我们开始在UI展示上探索，是否个性化智能化的展示能为业务带来提升。

在邮件/日历/SNS等客户端里，客户端数据要不断与服务端进行数据同步，在同步过程中，只拉取有修改的数据，称为增量更新，增量更新方案一般有两种，一是对比，二是日志。

How we improved thumbnails for HDR, interlaced, and 360° videos.

本文将介绍 Android 平台内存管理相关背景，阐述部分当代内存分配器设计细节。

得物App的图片、视频等资源有反馈加载较慢、有卡顿感。它们使用阿里云CDN进行下发，客户端与CDN服务器之间的请求耗时较长对用户体验产生了极大影响。

得物App核心的CDN域名共10个，其中流量最大的域名是cdn.poizon.com，占比92%，使用场景包括图片、视频、H5资源、小文件等，涉及得物App全域。

因此，本文主要以cdn.poizon.com为主讲解CDN网络性能优化过程。

数坊活动驾驶舱在大促活动期间基于用户购物流程，帮助品牌实时追踪、实时营销。

为了更优雅且通用的支持众多App的账号登录，我们推出了这套基于CV的智能注册/登录方案，可支持一键登录、微信登录和手机验证码登录三种登录方式，可登录各种非游戏竖屏App，并已在字节内部投入使用。

有声书市场近3年逐年递增35+%，仍处于增长期；各在线阅读平台重点布局有声书赛道，通过更优质、更多种类的有声内容，吸引并培养用户习惯，拓展市场。 在此背景下，如何增强用户听书代入感，以及如何高效批量生产高质量有声读物，是平台亟需探索的方向。

本文主要介绍阅文TTS合成平台架构，以及如何利用网文领域沉淀的文本算法，对小说进行自动文本预处理，并自动生成多角色、多情感、多场景的结构化画本，同时通过TTS有声书制作平台，将AI画本与TTS语音技术相结合，利用平台化功能如文本精修、添加音效、管理音频等，从而产出高质量的商用多播类有声作品，并在站内外分发投放。

优惠券系统在业务层面承接O2O一小时达业务核心促销，是京东到家营销工具的核心利器，为了支持复杂的业务和高流量的场景，对缓存Redis的应用必不可少。本章内容主要介绍京东到家优惠券系统的架构演化，以及承接高流量的Redis集群实战经验。本文的数据支撑进行了脱敏处理，如有不清晰之处，请见谅。

从埋点的定义、规范以及数据质量要求开始，介绍爱奇艺在治理埋点数据、提高埋点数据质量工作中的一些实践经验。

如何平衡？SourceMap正是解决这个矛盾的利器。