1.可演进的API1.1.随着需求的变化，你需要改变你的API，即代码之间的共享接口1.2.改变API很容易，但很难做到正确1.3.保持API小巧1.3.1.小巧的API更易于理解和演进1.3.2.只添加即刻需要的API方法或字段1.3.3.带有许多字段的API方法应该有合理的默认值1.3.3.1.开发人员可以只专注于和自己相关的字段，因为它们会继承其他字段的默认值1.3.3.2.默认值可使大型API在感觉上很小巧1.4.公开定义良好的服务端API1.4.1.切记使用标准工具来定义服务端API1.4.1.1.OpenAPI通常用于RESTful服务1.4.1.2.non-REST服务则使用Protocol Buffers、Thrift或类似的接口定义语言(interface definition language，IDL)1.4.1.3.接口定义工具自带代码生成器，可以将服务的定义转换为客户端和服务端代码1.4.1.4.文档也可以被生成，测试工具可以使用IDL来生成stub数据和模拟数据1.5.保持API变更的兼容性1.5.1.向前兼容1.5.1.1.向前兼容的变更允许客户端在调用旧版的服务时使用新版的API1.5.1.2.一个正在运行1.0版API的网络服务，但可以接收来自使用1.1版API的客户端的调用，这就是向前兼容1.5.2.向后兼容1.5.2.1.向后兼容的变更：新版本的库或服务不需要改变旧的客户端代码1.5.2.2.如果针对1.0版API开发的代码在使用1.1版时能继续编译和运行，这种变更就被称为向后兼容1.6.API版本化1.6.1.随着API的不断演进，你将需要决定如何处理多个版本的兼容性1.6.2.完全向后兼容和向前兼容的变更意味着API的所有的历史版本和未来版本都可以相互操作1.6.3.你会想变更你的API，使之与旧的客户端不兼容1.6.3.1.当客户端代码难以变更时，API的版本管理最有价值1.6.4.版本化你的API意味着你在做出改变时将引入一个新的版本1.6.4.1.API版本化自有其代价1.6.4.2.旧的主版本服务需要被维护，修复的bug也需要回传到以前的版本1.6.5.API版本通常由API网关或服务网格来管理1.6.5.1.管理版本所采用的方法要务实1.6.6.将文档与你的API一起保持版本化2.可持续的数据管理2.1.API比持久化数据存续的时间更短2.1.1.一旦客户端和服务端API都升级了，就意味着工作完成了2.2.隔离数据库和使用明确的schema将使数据演进更易于管理2.3.数据库隔离2.3.1.共享的数据库很难演进，并且会导致丧失自主性2.3.1.1.图
2.3.2.拥有共享数据库的应用程序可以发展到直接依赖对方的数据，应用程序应该作为它们所使用的底层数据的控制点2.3.3.隔离的数据库只有一个读取者和写入者2.3.3.1.其他所有流量都通过远程过程调用2.3.3.2.图
2.3.4.隔离数据库为你提供了共享数据库所不具备的灵活性和隔离性2.4.使用schema2.4.1.僵化的预定义数据列和类型，以及它们演进的重量级过程，会导致流行的无模式(schemaless)数据管理的出现2.4.2.无模式并不意味着“没有模式”（数据将无法使用）2.4.3.不要将无模式的数据隐藏在已经模式化的数据中2.4.3.1.隐藏无模式的数据是“自取灭亡”，你获得了显式schema的所有痛苦，却没有任何收益2.4.4.无模式数据有一种隐含的模式，可以在读取时被提供或推断出来2.4.5.采用无模式的方法会产生明显的数据完整性和复杂性问题2.4.6.强类型的面向schema的方法降低了应用程序的隐蔽性，因此也降低了其复杂性2.4.7.为你的数据定义明确的schema将使你的应用程序保持稳定，并使你的数据可用2.4.7.1.明确的schema会让你在编写数据时可以对其进行合理性检查2.4.7.2.使用显式schema解析数据通常会更快捷2.4.7.3.架构还可以帮助你检测到前后不兼容的变化2.4.8.数据有时被描述为“一次写入，多次读取”，使用schema可以使读取更容易2.4.9.schema自动化迁移2.4.9.1.改变一个数据库的schema是危险的2.4.9.2.可以管理数据库迁移的工具2.4.9.2.1.Liquibase2.4.9.2.2.Flyway2.4.9.2.3.Alembic2.4.9.2.4.GitHub的gh-ost2.4.9.2.5.Percona的pt-online-schema-change2.4.9.2.6.Skeema2.4.9.2.7.Square的Shift2.4.9.3.大多数迁移工具都支持回滚，也就是可以撤销迁移产生的变化2.4.10.保持schema的兼容性2.4.10.1.写入磁盘的数据也有和API一样的兼容性问题2.4.10.2.变更数据捕获(change data capture，CDC)是一种基于事件的架构，将插入、更新和删除操作转换为下游使用者的消息2.4.10.3.数据仓库管道和下游用户必须受到保护，以免遭受schema变更带来的不良影响2.4.10.4.兼容性检查应该尽早地进行，最好是在提交代码时通过检查数据库DDL语句来进行2.4.10.5.独立的数据产品，可能只是数据库视图，允许团队与数据的消费者保持兼容，而不必冻结其内部的数据库schema