幽默1：多亏了微服务，我们的JOINS(SQL语句)现在可以跨HTTP了。
banq评：SQL的JOIN是跨表操作，这种跨表操作可能会将本是松耦合的两个数据表耦合在一起，变成一个整体，相互绑架，无法各自独立扩展。如果使用DDD的有界上下文设计微服务，清晰划分好微服务的边界，微服务之间如果需要通讯，通过松耦合的消息机制联系，而不是直接把SQl JOIN操作延申到微服务之间操作，通过HTTP实现微服务之间实现同步调用，完成类似跨表实现的功能。
这种方式其实还是数据库思维的延续，或者说，当进入微服务世界，却没有引入DDD来管理数据操作，没有引入DDD对微服务进行指导制约设计：
DDD>微服务>SQL JOINs |
如果缺少DDD只是，则变成：
SQL JOINS>微服务 |
因为SQL和DDD都是解决业务问题不同的方式，而微服务只是一种技术架构，只是强调微小，而没有说明如何变得微小，DDD的有界上下文是说明如何切分变得微小，如果你的认知中没有DDD这种思维，那么你又要实现微小的业务功能，那么最终变成使用SQL JOINs通过HTTP整合多个微服务实现一个大的整体功能。
幽默2: 10年前，我们拥有一个难以管理的整体，其中包含数据库和服务器端渲染的Web前端。 现在，我们有了一个无法管理的NoSQL数据库系统、复杂的JS前端以及微服务的死星。
banq评：引入微服务和NoSQL以后，系统从过于集中走向另外一个极端：过于琐碎，这样的系统一盘散沙，难以管理，微服务+NOSQL=切断耦合，但是不是所有耦合都能切断，代表事物天生自然的耦合就无法切分，比如窗户由玻璃和窗框组成，这·三者耦合是一种聚合，天然组成在一起才代表一个窗户，否则分开就没有窗户这个事物存在了。
微服务和NoSQL只是指明方向，需要切断耦合，但是没有告诉我们如何保留聚合，放弃普通关联关系，也就是高聚合低关联，DDD的有界上下文和聚合体现了高聚合低关联的设计原则，因此，微服务+NOSQL组合中如果没有DDD，必然也会走向失败。