产品整体能 get 到大致的概念和思路，但是不能在最短的时间内给到用户足够的信息，无论是视频也是，文档也罢，最好能 10s 内能知道这个应用模块能做到哪些能力，能定制哪些部分，部署成本高不高，是不是足够傻瓜。我觉得目前获取信息的成本有点高。

我觉得我最早看到的觉得还不错的产品宣传视频是 http://zrey.com/app/markeditor
还有很多 youtube 上的技术产品都是有视频广告的，感觉都可以借鉴

@wizzer 很多时候我们 fail 一个同学的简历就是这样的，一句话就看出一个人是真懂还是假懂。建议看一下 https://www.youtube.com/watch?v=XjMTDb20O7M，先弄明白什么是微服务，什么场景下使用微服务再说吧。唉，一线互联网在强势输出技术概念的时候，往往都会一个层级一个层级的被扭曲

@charlie21 你说的对，但是我也只是把我的观点带出，至于后续的部分，不是我能完全靠评论解释的通的。而且不抱着一本红书结合手上的复杂业务，是无法完全理解 DDD 的概念的。我们团队也走了两三年的历程才有一些自己的理解

@wizzer 单体的微服务项目，你是对微服务有什么误解么？一个 web 开发脚手架（框架？）怎么就和微服务框架扯上关系了，omg。

微服务只是部署层面的拆分，代码层面一样可以做到逻辑的解耦和规划，可以了解一下 DDD

微服务原本是为了组织结构为研发带来的壁垒，推荐可以了解一下康威定律，就会更深刻的理解微服务解决的本质问题是团队分工
[和业务体量、业务复杂度的关系其实没有大多数人想的那么大，只是微服务顺手解决了这些问题而已]

楼上大多数人对微服务几乎只有 [术] 上的了解，对其 [道] 毫无所知

微服务的研发成本、部署成本、维护成本都是显著上升的，正如我们知道的”世界上没有完美的架构“，所以微服务是带来了一些问题，从而解决了一些问题

所以！
总结一下！
你的希望是自己的服务可扩展性和可维护性，你还记得大学课本里面说啥了没？

高内聚，低耦合

微服务只是在部署维度尝试做了这些事
那么微服务高内聚的是什么？是业务
微服务低耦合的又是什么？组织结构和团队

而你的关注点在哪儿？在代码本身，那么这个维度怎么解决呢？就是代码的纵向和横向的设计与拆分，可以好好参考一下 DDD，可以直接用其作为你的战术也可以简单参考一下，anyway，做一下你的领域设计，设计出一个可以运行好多年的架构出来吧。

加油。

楼主简直毫无同理心，也不了解如何面试。
小公司的综合素养就是会差一点，动不动就秒天秒地秒空气了，相反很多阿里的 P7，P8 都非常谦虚

想当网红啊

@chendy 恩，国内互联网尤其不喜欢 http 状态码区分成功失败，因为几乎没有大厂的 C 端业务完全适合 restful，而假设不玩 restful 的完全范式，其所谓的统一接口（ Uniform Interface ）也就没有意义了，自然就是放飞自我，各自团队各自规范，协议层也没啥特别统一的必要了。
还有最重要的一点，劫持太严重了，走 http 状态码实在是不行。。。

今年阿里晋升又是一轮放水，里面一堆水货 P7 P8

@xfriday 不可变对象就是解决的数据竞争，代码如果是 immutable 风格的就是天然不存在并发问题的。至于线程间数据共享你认为还要上锁，是因为你用了 immutable 的 rust 写出了 java/c++的代码，不可变对象是通过 copy on read/write 来解决并发问题的。理论上不存在两个线程共享一个引用的问题

无限扩展意味着没有明确的问题域，没有问题域是推导不出解决方案的。

真正的无线扩展就是啥都没解决，接入的时候再提出对应的问题域来解决

这不多

鄙视联想

额，为啥没有什么项目介绍，不太看得出来这个项目具体是做啥的。而且没有 doc 文件夹也没有任何 wiki。
起码告诉我们具体解决了什么问题。。。

MBP，其他都不够好。虽然我自己平时还是用自己的台式 Linux 更多

为什么会觉得不在应用层做这个事情更好呢？
为什么不让存储层职责单一呢？
如果下一次需求变更你的 SQL 该怎么改呢？
你为什么会觉得维护 SQL 比维护代码容易呢？
为什么不让近似的逻辑封装在一起来避免领域逻辑外泄呢？

别光爬啊，多用用我司产品啊。再爬就给你们爬倒闭了呀

@zek 为什么这么觉得。。。天哪

看你的场景咯。你对性能有需求么？有的话还是不要正则了。另外，这种简单场景正则真的有利于维护么？？？