在 SAP Cloud Application Programming Model 项目里，最容易让团队迷路的，往往不是不会写CDS，不会接SAP HANA Cloud，不会暴露OData V4服务，而是过早地认定什么叫美，什么叫善。一个模型看起来很完整，于是我们不断往里面加抽象。一个服务看起来很统一，于是我们把所有业务动作都塞进同一个ApplicationService。一个注解看起来很强大，于是我们把所有 UI 诉求都寄托给UI.LineItem、UI.FieldGroup、UI.SelectionFields。项目刚启动时，这些选择都显得漂亮、正确、先进。可到了集成测试、租户扩展、版本升级、性能压测、权限审计、灰度发布时，当初被大家称作美的东西，反而可能长出另一面。
老子说「天下皆知美之为美，斯恶已；皆知善之为善，斯不善已。」这句话放进 CAP 开发，不是在否定设计之美，也不是劝团队放弃工程规范，而是在提醒我们，凡是被绝对化的美，都可能逼出它的反面。CAP 本身就有很强的这种气质。SAP 官方文档把 CAP 描述为用于构建企业级云应用的模型、库与工具体系，并强调它提供许多开箱即用的最佳实践；文档首页也把「关注领域」「表达意图而不是过程」「关注点分离」「降低技术债」放在核心位置。也就是说，CAP 的美不是炫技式的美，而是让业务意图、运行时框架、数据库持久化、服务协议、云原生运维之间保持适当距离的美。(Capire
