谢谢回答！那在这一步，填数会遇到技术问题，还是规范问题？正如我的质疑，还是为了让逻辑和物理解耦而解耦，但是对于使用者来说，还包括了业务，与非技术人员，他们应该不需要关心这些，呈现了这些在最上端的产品层面，是不是没办法兼容到他们使用的习惯啊？

好的，按照对主数据概念的理解，数据标准的建设，是不是在维护主数据的治理工作？

谢谢，回答的挺认真的，学到好多！所谓的物化，只是物化的表结构，不存在物化的结果。也就是物化等于建表，不负责填数是吗？如果是的话，数据架构阶段，其本质就是为主题域的一些业务对象构建物理表，且不填数。那这一步为什么不能在【数据开发】ETL脚本实现，只创建一次。另外在【数据架构】模块，有没有可能实现已创建好的主题域，业务对象，维表，事实表的拖拉拽的etl？如果可以的话，我最终的问题是【数据架构】，【数据开发】解耦的究其原因是啥，是不是为了解耦，而解耦？

谢谢回答，并没有揉在一起，构建主题域组，主题域，业务对象，码表，指标时，完全可以让物理表与之关联，层次很分明。只需要拉起调度任务。从主题域组至指标都会产出结论。所以没有必要在启动数据开发模块，每个模型层把逻辑开发一遍。反而在看DGC的文档，这两个模块在穿插，分工不明确，更像是来回揉堆，重复储存与开发。完全使用【数据架构】，逆向填数数据，拉起作业调度，就实现了真正的低代码平台。完全使用【数据开发】，就是代码平台。两者捆起来用，我不知道是低代码平台还是代码平台。产品对外是说，它是低代码平台。很矛盾