先建模型还是先建数据库：短迭代周期原则

建立数据库映射时通常面对三种情形：自己选数据库方案（最自由）、必须映射到不能改的现有数据库、必须映射到可以考虑修改的现有数据库。当可以自由选择方案且逻辑简单时，直接围绕数据设计表、用行/表数据入口剥离SQL即可；如果用领域模型，则应该先不受数据库牵制地建模，把数据库设计单纯看作持久化对象数据的一种手段——数据映射器给了这份自由，但也带来复杂性，如果数据库设计和领域模型碰巧同构，也可以退而用活动记录。但”先建模型、后建数据库”这个原则只在短迭代周期内才安全：花6个月建一个完全不碰数据库的领域模型、指望做完再一次性持久化它，是一件非常冒险的事，因为往往会因为迫切的性能问题被迫大量重构去修补设计；正确做法是每次迭代都同步建数据库，迭代长度不超过6周、越短越好，这样才能持续、快速地获得数据库交互实际表现如何的真实反馈。当已经存在数据库方案时，思路类似但过程不同：领域逻辑简单就直接建行/表数据入口模拟数据库、在其上搭领域逻辑；领域逻辑复杂则要逐步建立领域模型加数据映射器，把数据保存进既有的数据库结构里。可迁移启发：任何”先设计得纯粹、之后再对接现实约束”的工作方式，只有当反馈闭环足够短（数周而非数月）时才安全——闭环越长，设计和现实脱节的风险积累得越隐蔽、越危险。