做一个实用主义者。如果你被其他车子插队了，直觉上首先会感到愤怒，但是想一想这也耽误不了几秒钟。
如果你为这几秒钟感到生气，那你就在做“用别人的错误惩罚自己”（生气会让人健康受损）

我认为 n.n.taleb 的一个原则很适用：
> 面对恶心的人，要么完全忽略他，要么将他完全打倒。

在行车的过程中就是：如果别人违反规则让你感到恶心，你千万别用生气惩罚自己，绝大多数时候时候直接忽略他。如果同一辆车多次故意别你车，那么如果今天没有什么特别急的事情，直接干他吧（当然注意别构成违法）

发现某个 JWT 库因为 Json 解析的逻辑在某些情况下会导致安全隐患，然后在文档中添加了警告与例子，PR 被接受了。

回答楼主：

thoughtworks 的一个 Java DDD 范例项目：
https://github.com/e-commerce-sample/ecommerce-order-service

微软官方的 ddd 教程项目（.Net ）：
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/
https://github.com/dotnet-architecture/eShopOnContainers
https://github.com/dotnet-architecture/eShopOnWeb
（虽然是.Net ，但是 AspNet 和 SpringBoot 差别不大）

回复楼上那些说 DDD 不实际、DDD 只适合大公司的复杂业务等说法：
CRUD Boy 无法理解 DDD 属正常现象，但是如果轻视 DDD，那就注定只能当一个低级的 CRUD Boy 。

C 井，少发一音节的音，并且中国程序员之间互相理解也不存在问题。（虽然我一直念 csharp ）

首先是 rust vs 有 GC 语言。如果一个应用场景使用带 GC 语言（例如 java C# go ）是普遍的解决方案，那么在这些场景下使用 rust 就是自找苦吃（选择了麻烦的抽象层级、选择了不好招人）

所以要清楚 rust 对标的是啥，是 C++，而不是其他的那些语言。如果你的工作中用不到 C++（比如我），那么对于这类讨论的态度就是吃瓜就好。

将所有消息再存一份即可

这是一个人际关系问题。

如果你嫌 with 多了一层缩进的话，C#的 using 很满足你的需求。using var reader = xxx;

总结一下楼主的表述.
前提：我中了彩票。推论：彩票不是真的随机。

火绒没报毒

本地不一定要用“杭州”这一类名字啊。例如成都市或者四川省可以用“蜀”、“天府”之类的名字，数不胜数。

Mate10 裸奔一年半，摔了无数次，没碎

@killsting 我最近 2 个月内刷 b 站有时退出全屏的时候卡死，不知道是不是 adblock 的锅。

@gateoflunar 没有啊。getadblock.com 里面有链接指向 edge 商店那个 adblock （附言里面的），并且 chrome 商店最高下载量 adblock 的详细信息页面有链接指向 getadblock.com

@SunKnight88 谢谢提醒，貌似破案了，是 angular 、油猴、adblock 三个插件之一的问题。目前三个插件全部禁用了，暂时没发现高 CPU 开销。我等会儿挨个看看是哪个插件的问题。

后端只学 webapi 就行了，学会了可以无痛过渡到 springboot 。其他的学了也用不上。教程在 https://docs.microsoft.com/zh-cn/dotnet/

哈哈哈，除了最后一点，其他的自己去领悟。

某个框架的某些特性看似设计垃圾，当你明白了为什么要这么设计的时候，就证明你代码能力提升了。

Microsoft TODO 的同步逻辑偶尔也会出问题，会出现周期待办事项的子事项被全部勾选的问题，2 年了，还没有解决。另外还会出现不提醒的问题（害得我偶尔错过防疫打卡）。

第一个问题：分开做 2 个接口、合并为一个接口 这两种做法，从写代码层面上来说，普通程序员是可以轻松实现的，不存在困难。

但是，最重要的是，要考虑到前后台 Api 在之后的开发阶段会不会朝着不同的方向演化。

现在阶段，前后台 Api 的差距，看似只是返回信息的数量的差距。
但是，在之后的开发阶段，两个 Api 可能朝着不同的方向演化，并且二者的差距越来越大。
面向后台的 Api 可能会附带上其他的监控方面的数据，面向前台的 Api 可能会附带其他的向用户展示的数据。

如果之后这样演化，那么再继续共用一个 Api 地址，就显得很混乱。面向后台的 Api 的修改，很可能牵涉到前台的变动。

所以，第一个问题的核心，就在于两种 Api 在之后会不会朝着不同的方向演化。

---

第二个问题：这是 overfetch 的问题。一个可选的解决方案是 graphql 。此外，如果要在 restful 基础上来改进的话，就应当偏向于返回更多的数据，来降低开发中需要考虑的情况数量。

返回更多的数据会造成 overfetch，会造成带宽资源的消耗，同时也会降低开发的复杂度。并且，如果带宽资源不紧张，就可以不管。
如果带宽资源紧张，根据二八定律，只有那 20%的接口最消耗带宽，所以就只需要用某种带宽资源的 profiler 找出最消耗带宽资源的那四五个的接口进行修改，让它们不要返回过多信息，或者拆分为更细粒度的接口。