不同系统之间字段统一

[DingJZ]

比如一个订单号，有的系统叫 orderCode, 有的叫 orderId, 有的叫 orderNo, 最后就是上下游系统、数据库，前端、后端字段都乱七八糟

这事有没有解，或者大厂是怎么做的

[frandy]

不同的系统由不同的开发人员开发,这种名词统一,一方面是代码 CR 问题,
对于同一系统内部一个名词从表结构到出口都一个名词定义,
系统和系统之间调用,得到的响应值做一次名词转化。
那现实世界来说,一个番茄南北方叫法还不同呢,不同的地区还叫法不同呢
这是无法避免的,只能说到了自己这儿,自己做个名词转化,尽可能保证自身系统的字段统一。

[ryougifujino]

可以去看一下 DDD 相关的书籍，就好理解了。其实这种不同就是因为限界上下文的不同造成的。只要在限界上下文之内形成统一语言就可以了。

[37Y37]

你如果接过云厂商的 SDK/API ，你会发现大厂更乱，不仅乱还会给代码下毒

举一个例子，对于返回数据有创建时间的，有的字段名叫 create_time ，有的叫 created_time ，有的叫 createTime ，有的叫 createdTime ，有的返回 UTC 时间，有的返回本地时间，有的返回时间类型有的返回字符串，有的返回时分秒，有的返回时分，这些还都是同一家云产品，只是不同接口而已

再举一个例子，获取分页数据，有个 offset 的参数，通常情况下都表示偏移量，但有些时候人家偏偏要让它表示页码 page num ，关键是同一个产品不同的接口同样都是 offset 参数，有的表示偏移量有的表示页码

最近在接各大云的 SDK 被搞蒙了，接了大小 n 个云厂商，每个都有这情况，没有例外

[imycc]

作为用户我的做法是将 API 拿到的结果再封装两层，第三方系统 -> APIRequest 封装（分页、鉴权、异常处理等） -> 业务抽象（名词转换及方法封装）-> 自己的业务。
不知道那些做 toB 业务的大厂有没有更完善的规范，一个产品不同子业务也是多个人在开发的，想要风格统一，光靠自觉没用，还得有技术评审流程。
我们搞内部系统通常就很放飞自我了，主要是当你参与进来的时候，现状已经很乱了，A 团队一个用法，B 团队一个用法，你总得选择一个。。

[Suddoo]

没办法，看 yapi （或者别的什么工具）上维护的接口说明，以这个为准，避免扯皮

[darksword21]

@37Y37 在此点名华为云一下

[Saxton]

大厂都有这个问题， 你没事可以打开浏览器按 F12 看看请求 你会发现一篇新大陆的

[MarioLuo]

梳理一份常见字段命名(业务和非业务)，数据库评审阶段可以卡