在我这个没写过 Java 项目的外行看来，面向接口编程应该是没什么问题的，准确来说是面向抽象编程，但并不是所有东西都需要抽象，以“考虑未来 /拓展”为理由产生的过度抽象是应该避免的。

关于 Getter/Setter：同 56 楼，是面向对象保持封装性的一部分，但是我个人认为如果你开发的是一个类似 Spring 这样需要一步步发展完善的大型工程项目，那封装是很重要的，反之如果只是写简单的业务逻辑，以后很可能整个 Model 都推翻重来，也不会有人在你这个项目之上再去拓展（感觉一般的 Web 项目模型都不会再作为其他项目的基础了），那么对于不需要限制修改的属性，完全可以写成 public 的。

其他内存问题我不了解，不过直觉多一个 JVM ，不管怎么都不可能和直接在对应平台上编译效果一样吧。

确实是组的问题，写业务最佳的状态是人家把轮子都造好，你只要专注在业务逻辑上就可以了。
但是当你的业务代码已经优化到很难继续提升时，你可能需要考虑一下你用的这些轮子上还有没有提升空间，然后理想的状况就是去研究这些东西然后优化它们。

当然实际上这些工作已经有专门的人在做了，那就大家在自己负责的领域努力做好然后去做下一个，人人都是螺丝钉了……大不了干几年出去创业嘛。

@Aoang
@lessMonologue
@TinyKube

谢谢各位回复，最后在翻阅标准库的注释时找到了比较官方的解决方案：实现 Marshaler 和 Unmarshaler 接口即可，也就是说为每个 struct 定义 MarshalJSON 和 UnmarshalJSON 方法，之后即可使用标准库 json 进行自定义的序列化和反序列化，也解决了私有属性的序列化问题。

@Aoang 感谢，我再尝试一下哪种方案更好用吧。

@lessMonologue 全大写的话意味着破坏了封装性，不过如 Python 之类的语言同样也淡化了这方面的限制，我不太清楚这样做是否会带来什么问题。

@Aoang 意思是不要把结构体严格等同于其他语言中的类，在需要时创建匿名结构体来满足需要就可以了吗？

@ch2
@honkew

写完发现有个地方没讲清楚，想补充但是超过可编辑时间了，情况是这样的：

我的领域模型中属性默认都是非导出的（即小写字母开头），这种情况下没法直接添加 json tag 来做序列化，所以我很纠结，是为了序列化将属性改为 public ，还是应该定义一个新的 struct 用来做序列化。

我从来没用 Java 写过项目，但最近甚至想去研究一下 Spring 的源码……Java 好东西多着呢。
当然，烂大街也是真的……

大概是反向吊打，有想法需要验证的时候都是拿 Python 先写一遍的……

前篇地址 404 ，不过通过 blog 找到了，支持干货。
说到 Google API Design ，Golang 主流的 router 在处理 URL 参数时都选择了冒号前缀，很难受;(

@zh6335901 感谢回答，我也觉得确实应该考虑一下返回 Id

@lmshl 直接写入 Kafka 的话重放时调整 offset 来实现吗？请问还有什么需要注意的地方吗？

@staticage
1. 我的第一个问题在于这个创建对象的接口是不是不应该返回值，如果是这样的话，后端生成的 uid 前端是获取不到的。
2. 第二个问题的主要疑惑在一致性问题上，举例来说，假如我使用关系库存储事件，用任意 MQ 分发，那就会在一个操作中涉及到两个组件（关系库和 MQ ），我要如何保证这个操作的原子性（即避免出现消息发送成功但事件存储失败之类的情况）？

女朋友+1

暴露了表结构可能是一个问题，另外如果冗余数据的内容非常多导致传输受到影响也不好。
除此之外其实没什么太大的问题，而且我个人的看法是少量的计算和格式转换交给前端做更好，毕竟前端的计算压力分散在每一个客户端（浏览器）上，而后端处理则是一台服务器处理所有请求需要的数据，显然前端处理可以分散压力。

当然实际项目中大部分人这么做是因为懒（摊手

这个好办，公司换装 Linux

科班学啥你学啥就行了。
反正大部分都是自己学出来的。

楼上说的对，对同事要求太高，需要你做架构师

所以不建议水平不够的人写 Python ，更不建议和水平不够的人合作 Python 项目
语言没有约束，就只有靠程序员自己去约束了

图做得真好
可惜用了 vim 后就不想再折腾这些了

32 的，基本没听到过声音，目前能感觉到发热的使用场景只有剪视频和开 OBS