接上条，要想润，什么都不重要。

决心最重要。

--------------------------------------------
99%的人润不了。

99%的人润不了。

云原生就是跑在云上的运用，例如 kubernetes 云，云原生应用就是针对 kubernetes 这种(操作系统)开发的应用。

《季氏将伐颛臾》

季氏将伐颛臾。冉有、季路见于孔子曰：“季氏将有事于颛臾。”

　　孔子曰：“求！无乃尔是过与？夫颛臾，昔者先王以为东蒙主，且在邦域之中矣，是社稷之臣也。何以伐为？”

　　冉有曰：“夫子欲之，吾二臣者皆不欲也。”

　　孔子曰：“求！周任有言曰：‘陈力就列，不能者止。’危而不持，颠而不扶，则将焉用彼相矣？且尔言过矣。虎兕出于柙，龟玉毁于椟中，是谁之过与？”

　　冉有曰：“今夫颛臾，固而近于费。今不取，后世必为子孙忧。”

　　孔子曰：“求！君子疾夫舍曰欲之而必为之辞。丘也闻有国有家者，不患寡而患不均，不患贫而患不安。盖均无贫，和无寡，安无倾。夫如是，故远人不服，则修文德以来之。既来之，则安之。今由与求也，相夫子，远人不服而不能来也；邦分崩离析而不能守也；而谋动干戈于邦内。吾恐季孙之忧，不在颛臾，而在萧墙之内也。”

@wd DDD 核心是 domain ，domain 相当于抽象出了你核心的 business 模块，剩下的表示层、数据库 DTO 层都是从属。这样带来的好处是表示层、数据库层和 domain 层完全解耦，数据库的结构变化不影响 business ，表示层更是可以自己实现 aggregate 各 domain 层，提供数据 view 出去(和三层架构 MVC 对比)。业务功能开发程序员可以专注于实现 business logic 。

当然，任何好处都是 trade off 的，带来的弊端是 data model 需要在表示层、domain 层和 DTO 层频繁转换，对性能可能有一些影响。另外，如何更好的 DDD 设计，特别是 domain 的设计、聚合根、实体类的设计，都需要摸索。

可以看一下目前的 DDD 典型架构，洋葱模型和六边形模型，JAVA 的 demo 到处都是。

论语的《季氏将伐颛臾》，如何？

季氏将伐颛臾。冉有、季路见于孔子曰：“季氏将有事于颛臾。”

　　孔子曰：“求！无乃尔是过与？夫颛臾，昔者先王以为东蒙主，且在邦域之中矣，是社稷之臣也。何以伐为？”

　　冉有曰：“夫子欲之，吾二臣者皆不欲也。”

　　孔子曰：“求！周任有言曰：‘陈力就列，不能者止。’危而不持，颠而不扶，则将焉用彼相矣？且尔言过矣。虎兕出于柙，龟玉毁于椟中，是谁之过与？”

　　冉有曰：“今夫颛臾，固而近于费。今不取，后世必为子孙忧。”

　　孔子曰：“求！君子疾夫舍曰欲之而必为之辞。丘也闻有国有家者，不患寡而患不均，不患贫而患不安。盖均无贫，和无寡，安无倾。夫如是，故远人不服，则修文德以来之。既来之，则安之。今由与求也，相夫子，远人不服而不能来也；邦分崩离析而不能守也；而谋动干戈于邦内。吾恐季孙之忧，不在颛臾，而在萧墙之内也。”

最后一句，真觉得太经典了，两千多年前的道理啊，现代人能体会么？

“远人不服而不能来也；邦分崩离析而不能守也；而谋动干戈于邦内。吾恐季孙之忧，不在颛臾，而在萧墙之内也。”

吾恐季孙之忧，不在颛臾，而在萧墙之内也！

@Biwood 经典名句！赞~
“有时候在骂别人“吃屎”的时候，换个角度，可能因为自己就是屎。”

可以通过一些办法在中间层加强管理啊，一段时间看下效果，再就是 review 下代码。
不过做成这样是不是钱给太少了，或者和老板的关系招来的啊~

你需要一个老婆。

以前的单体服务 MVC 的时代和实现的微服务时代，都不同，演进很多代了。
现在的微服务时代，数据库设计是轻量级的。例如外键，以前很流行，现在基本不用了。
建议从项目实践中模仿到提升，从设计 1：1，1：n 开始，到 n：n 。很多时候不走一些弯路是不知道为什么那样设计不好。

做开发机现在 M1 已经 OK 了？对比 Intel 芯片

大宝剑。

B 站油管找个 JAVA 语言的基于微服务的系统，跟着做就行了。
一般现在主流的有两个路线，一个是完全的 JAVA 栈，spring cloud 框架； 一个是 k8s，应用 java 写，docker 镜像部署到 K8s 集群。
看看自己想学哪个。

年轻人，别去小地方，要去就去 BAT，赚一两百万！
问题是。。全中国有多少人能进 BAT 啊。。说得就像 BAT 等大厂是你垫底的选择。。

@jack778 业余时间做点事，以后就真能一直躺平？

不是应该是 C 语言么？