我最近和一位同事进行了一次非常有趣的讨论。他只有几年的编码经验，没有任何工程背景。他认真地试图说服我使用 ame模型来表示实体，业务和持久性实际上被认为是最佳实践。
我们在同一个项目上工作。它基本上是一个提供JSON并使用MongoDB数据库的Web API。对于所有实体，JSON响应，代码中的业务类和MongoDB文档都具有相同的结构。
我认为他的做法完全错了。他认为将这三件事分开，就像MVVM和MVC模式一样，这是老派的想法，因为每次创建新的业务实体时，都必须为JSON响应“编写映射代码”以及映射到MongoDB文档。
在设计业务实体时，他的设计方法非常奇怪：他从不使用继承或聚合/组合。他的逻辑是：“当我设计业务实体时，我必须牢记前端开发人员.JSON响应必须具有易于使用且可由前端代码访问的结构。”
代码中的所有业务实体，我的意思是，不会显示任何继承，聚合或组合的迹象。没有任何关联。每当有新功能出现时，他就会“设计”一个全新的实体。他还更改了已经在生产代码中运行的实体的结构（通过为新功能添加新字段），这不仅会影响MongoDB文档的加载方式（也可以加载），还会对JSON响应产生影响。换句话说，这完全破坏了代码的稳定性和API的可用性。
您怎么看？