这是一个创建于 917 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如一个订单号，有的系统叫 orderCode, 有的叫 orderId, 有的叫 orderNo, 最后就是上下游系统、数据库，前端、后端字段都乱七八糟
这事有没有解，或者大厂是怎么做的
 |
1
frandy 2022-05-25 20:49:30 +08:00
不同的系统由不同的开发人员开发,这种名词统一,一方面是代码 CR 问题,
对于同一系统内部一个名词从表结构到出口都一个名词定义, 系统和系统之间调用,得到的响应值做一次名词转化。 那现实世界来说,一个番茄南北方叫法还不同呢,不同的地区还叫法不同呢 这是无法避免的,只能说到了自己这儿,自己做个名词转化,尽可能保证自身系统的字段统一。 |
 |
2
ryougifujino 2022-05-25 22:27:34 +08:00 via iPhone
可以去看一下 DDD 相关的书籍，就好理解了。其实这种不同就是因为限界上下文的不同造成的。只要在限界上下文之内形成统一语言就可以了。
|
 |
3
37Y37 2022-05-25 22:39:15 +08:00
你如果接过云厂商的 SDK/API ，你会发现大厂更乱，不仅乱还会给代码下毒
举一个例子，对于返回数据有创建时间的，有的字段名叫 create_time ，有的叫 created_time ，有的叫 createTime ，有的叫 createdTime ，有的返回 UTC 时间，有的返回本地时间，有的返回时间类型有的返回字符串，有的返回时分秒，有的返回时分，这些还都是同一家云产品，只是不同接口而已 再举一个例子，获取分页数据，有个 offset 的参数，通常情况下都表示偏移量，但有些时候人家偏偏要让它表示页码 page num ，关键是同一个产品不同的接口同样都是 offset 参数，有的表示偏移量有的表示页码 最近在接各大云的 SDK 被搞蒙了，接了大小 n 个云厂商，每个都有这情况，没有例外 |
 |
4
imycc 2022-05-25 23:58:42 +08:00
作为用户我的做法是将 API 拿到的结果再封装两层，第三方系统 -> APIRequest 封装（分页、鉴权、异常处理等） -> 业务抽象（名词转换及方法封装）-> 自己的业务。
不知道那些做 toB 业务的大厂有没有更完善的规范，一个产品不同子业务也是多个人在开发的，想要风格统一，光靠自觉没用，还得有技术评审流程。 我们搞内部系统通常就很放飞自我了，主要是当你参与进来的时候，现状已经很乱了，A 团队一个用法，B 团队一个用法，你总得选择一个。。 |
 |
5
Suddoo 2022-05-26 00:16:59 +08:00
没办法，看 yapi （或者别的什么工具）上维护的接口说明，以这个为准，避免扯皮
|
 |
6
darksword21 2022-05-26 00:26:21 +08:00 via iPhone
@37Y37 在此点名华为云一下
|
 |
7
Saxton 2022-05-26 09:46:33 +08:00
大厂都有这个问题， 你没事可以打开浏览器按 F12 看看请求 你会发现一篇新大陆的
|
 |
8
MarioLuo 2022-05-26 10:25:39 +08:00 via Android
梳理一份常见字段命名(业务和非业务)，数据库评审阶段可以卡
|
Select Language