@documentzhangx66 但凡你能说对一句...

得考虑团队整体水平，防止水平差的同事瞎用，干脆一刀切禁掉省事。比如楼上很多一把梭的我看就很危险。

DDD 是试图解决超复杂业务场景建模的一种方法，这东西十几年前国内就有人在研究了，但是实施落地非常难。
这几年随着微服务这阵风又热起来了，个人认为是因为早些年互联网的业务其实还算简单，不需要用到这些复杂的业务建模理论。后来业务越来越复杂于是微服务兴起，但是就微服务本身而言只是一套技术架构，并不是说无脑套用就能解决一切。最后还是要回到软件工程的一些基本问题，于是 DDD 又被重新拾起。

热门的不说了，提一个稍微冷门一点的，李沧东的《绿洲》

外包这个词的定义不重要，你关注的无非是公司的技术实力和自己的成长。

最早的时候我们说外包技术含量低，仅限于人力外包，因为外包人员只会被分配一些边边角角的 CRUD ，接触不到核心的框架和基础设施开发，甚至核心业务都很少接触。

至于把项目外包也包含进所谓的“外包”范畴，那情况就不一定了，有些专业的行业软件开发商本身就比甲方技术实力更强，可以类比现在的一些代工厂商。

写得一坨 shi 一样，属于编都不会编。

专线接入？

有些比较水的面试官又喜欢问八股，自己又没本事把问题深入下去，这种时候需要你自己主动展开来说。你能头头是道说一大堆他就觉得你不错，你自己不主动展开说他也没法判断你的水平，就没戏了。

第一个乍一看不觉得有问题，仔细看发现只是为了 equals 避免空指针写了这么一大堆 if ，改成 Objects.equals 就好。

如果是业务条件需要的类似判断场景，那么像图一这么写两层 if 嵌套其实比楼上一些人的全写到一个 if 括号里更容易阅读。

就是昨天，用百度导航到某景区停车场，它给的路线是驾车到景区侧门然后步行穿过景区内到达前门的停车场，我当场裂开。

全方位的优势，除了价格。
但是价格成本这东西怎么说呢，之前银行、运营商学着互联网搞“去 IOE”，去了这么多年还去不掉，很大一个原因就是你要自己养一个玩得转 MySQL 的团队，去优化，去定制开发，这个成本未必比直接用 Oracle 低。当然了，系统规模不大直接用社区版的 MySQL 也够了。

再以我作为软件开发者角度的使用体验来说，Oracle 下 sql 语句想怎么写怎么写，只要不是索引没覆盖到使用的字段，性能基本没问题。MySQL 就不行了，必须要熟悉 MySQL 索引背后的机制，熟悉 sql 优化的逻辑，一个不小心性能就爆炸。
所以很多大厂的规范也是不允许在 MySQL 下做 3 张表以上的关联；从 Oracle 迁移到 MySQL 时把复杂 sql 语句做拆分也是必须的步骤。
很久以前做过的一些系统里面不少 sql 语句几十行，甚至上百行，先不讨论这种代码是不是很烂，但它在 Oracle 下跑起来性能就是没啥问题。

@coderxy 不用微服务这套框架就不能自己拆分项目了么
太多人无脑套用微服务框架这套东西事实上就是徒增了很多没必要的工作。

你们这些觉得太闲会废了的赶紧回国，拼死拼活几年后就会发现，也并不能拼成个人上人...

我在想是不是现在的小朋友都不会写 sql 了 所以 jpa 这种东西才会这么热