如果我们的眼光只局限在技术层面，那么 DDD 对你而言有用的就是战术模式那一部分，也就是编码的那一部分。如果我们把眼光放高一些，着手解决整个产品研发生命周期的效率方面，或者 DDD 就能帮大忙。这不仅仅使我们工作更加轻松，更加快乐，也使得我们不会把时间浪费在一些经常反复出现并且很愚蠢的事情上面。当然这个愿望很美好，但是不一定每个人都想做得这么美好。

总的来说，DDD 分为两个部分，一个是技术实践的战术模式，一个是工程架构的战略模式。

其中，战术模式仅作为实现的部分参考，总结的是以面向对象范式编程语言的一些常用技巧与原则，提炼出了一些可以跟非技术人员沟通的构建单元，也就是你可以跟产品直接聊的一些东西，比如实体、值对象、仓库等等。

其实最重要的是战略模式，这部分也是大多数接触 DDD 的人觉得云雾缭绕的东西，看不见摸不着。团队规模小了，搞这些觉得繁琐，团队规模大了，面对已经成熟的 CRUD 基本上都有一套成熟的流程方案了。所以这个东西真正有价值的还是回归本质，解决软件核心中的复杂性。

首先你得是一个团队，否则的话一个人还搞什么 DDD 对吧？其次对团队里面的人也要有一定的要求，起码在沟通上，要明确价值。也就是说哪些信息对于不同岗位的人来说是明确的，是可以沟通的和达成共识的，哪些信息对开发或者产品来说就是废话，要把能够体现出真正用意的这部分提炼出来，在整个团队中进行传播和理解。

其次，有了高效的沟通和统一的理解以后，才能对同一个事物进行拓展（研发），需要在前者的基础之上，搭建一套能够迅速有效解决问题的工作流程，对产品进行高效的迭代。DDD 的战略部分就是基于前者，然后再结合一些准则和经验，帮助你如何解决更大规模的软件工程问题。

以上这些当然都是很美好的初衷，但是我个人认为，关键变量不在于每次迭代能否更进一步，而在于对人的管理，什么意思呢？人的不确定性才是最大的不确定性，人这个变量的影响范围如果能够控制住，培训也好，工作范围的划分也好，只要能够达到一种“柔性”的状态，终归会回归正轨。

说得有点多了，尽信书，不如无书，要有自己的思考。

还有谁记得“海贼-王路飞”？

nosql 大多都是分布式数据库，如果引入自增的这种特性，意味着每一次插入都需要协调维护一个计数器，这会引入额外的同步开销，因此最好是自己在应用层去维护这个计数器，而不是依靠数据库本身提供类似的功能。

语言用 C++是有优势，但是相比较之下，良好的架构更加重要，要兼顾到日常逻辑开发的便利性，如何权衡取决于公司的用人成本。用 Java 配合 Netty 已经足够承载绝大多数游戏类型了，并且招人也很方便。

游戏服务端一般是有状态的，而 web 开发大多数是无状态的，有状态就意味着容易出现单点事故，比如网络不可靠，机房出现故障，服务端宕机等等，因此就需要通过日志的方式来存储状态变更操作，尽量减少事故带来的影响。类似于 redis 的 AOF ，mysql 的 binlog 。

要知道大多数在线游戏后端主要是计算密集型的应用，跟 web 开发的区别之一就在于基本上所有的状态都会保存在进程内存中，目的就是尽量避免 IO 操作。数据库的作用仅仅只是用于存档落地，甚至简单的来讲都可以不要数据库，直接二进制文件也可以。比如我经常在开发调试的过程中将整个玩家对象序列化为一个 JSON 文本，特别方便用于测试的时候，设置各种玩家的快照还原。

还有很多关于游戏后端开发的知识要点，一次也说不完，比如线程模型，元数据（配置）管理，网络 IO ，二进制消息协议，GM 管理后台，第三方系统集成等等，是一个很庞大的内容。

值得庆幸的是，随着用户的爆炸增长，现代的服务部署以及运维都比以前要好上太多了，使用云服务和容器成本更低，更有保障，但一切的前提是要根据游戏类型选择合适的技术架构。

我用的阿里云的，223.5.5.5 、223.6.6.6 ，有没有大佬说一下优缺点？

如果你的表有几千万的数据，并且值是稀疏的，可枚举的，使用 int 会比 varchar 要少占用很多的存储空间，量变决定质变。

推荐一篇文章，讲解的比较系统： https://mp.weixin.qq.com/s/apUVMfAI52uvc7U-iOVvKg

干嘛一定要刻意的去戒呢，想起来了就放下嘛，主要是怕想不起来，比如在一条腿上面系上一本书啥的。

@fgd 全在这里了： https://developers.weixin.qq.com/miniprogram/product/material/

如果是游戏，还需要出版号，否则不能进行收费，这个已经很久没有发了。

补充一下：

首先是域名，这个需要 ICP 备案，公安备案。
如果是收费性质的，还需要 ICP 许可证。
安卓上架各大市场需要软著。

文化性质的，需要文网文，有 6 类：
1 、游戏类：游戏产品合规运营的准入许可，包含发行游戏币作为游戏里的流通货币；
2 、表演类：利用互联网进行网络在线直播表演；
3 、音乐娱乐类：网络文化经营许可证-音乐娱乐产品类经营；
4 、动漫类：利用互联网经营动漫画视听产品；
5 、展览比赛类：利用互联网进行网上文化产品的展览以及其他比赛活动；
6 、演出剧目类：利用互联网提供演出出节目的传播服务。

@haython 海外不清楚，不过我的认知是功能还是有，只不过没有国内这么严格，这个其实跟运营有很大的关系。国内的你懂的，V2EX 也被 BAN 了很久了。

包括用户的评论、上传、分享等一切 UGC 功能均需要审核，也就是平台自我审查，涉及到这些内容的均要耗费很大的精力来处理。

你说的事务都是技术执行层面的 [如何使用事务] ，猜测一下他应该想问的是业务层面的 [为什么 /什么情况要使用事务] ，一个是 How to do ，一个是 Why to do 。

不过仅从你描述的这些也只是猜测而已，假如说我来进行面试的话，一般就不会问具体的实现细节，而是问这个东西有什么用，为什么要用。

刚才大盘跌 4 个点了，看这阵势是止不住啊

最好在数据库层面进行并发控制，不要在你的应用层加锁。直接加一个字段使用乐观锁来保证在并发的情况下只有一个事务会成功。并且你需要问自己一个很重要的问题，那就是这个业务真的会有大量的并发请求针对同一个订单进行操作吗？

《卷王忏悔录》，开个玩笑，适当放松一下自己吧，等疫情稳定以后出去旅游一下。

如果没有基础设施的支持，不建议用不同的语言来开发。反之，如果用 Spring Cloud 这种的话，基本上就是几行配置就可以搞定，也不需要容器化。