说的接近了一些，但我把解决方案说的很清楚。
只不过你也没看明白，或者还没认识到，所谓代码耦合，所谓类或接口依赖，实质是思维依赖。如果解除这个依赖，即便是Java这种所谓“静态语言”也能表现出惊人的可变化性，如果解除不了，即便你们把系统拆解成微服务物理隔离，也是牵一发而动全身，修改一个核心服务影响的范围都是不可控。所以说起来微服务就是程序员们对复杂系统如何隔离分治感到穷途末路的产物，才是没有从根本上解决。所以，eight的线上系统就是用eight做的，全是由一堆部件组合起来的。你可以看看有没有解决问题。毕竟talking is cheap不是吗？

如何解决思维上彼此关联和思维依赖问题，这才是提供一组固定不变共识接口的原因。共识接口原本并不是为解决java的class依赖造成loader无法卸载设计的，虽然它客观上确实起到这种作用。它的关键在于对人的模块设计思维进行约束，也就是通过约束可用谓词来约束人对事物的表达，依靠的是共同经验的人对相同的事物有相似的表达，来使不同的开发者在开发彼此关联的模块时不需要（深入）沟通就能构建相互独立又彼此能够连接的模块。这样的组件自然是独立而少依赖的，自然容易被集成，动态装卸和更新。这就是原理。

说具体一点，给你个模块：实现一个爬虫模块，它从互联网上收集文本信息（它本身不含网页抓取模块）并按关键字计数保存。你把这个需求给你手下三个程序员，让他们独立开发不要讨论接口和实现细节，看看会写出来啥。约定只能使用共识接口的processor和resource族接口，看看写出来啥，几个人实现的差异如何？然后再让一个人用这两套接口实现一个抓取模块，另一个人实现一个关键字计数存取模块，都独立开发，完事你看组件能否装配在一起，如果不能，通过少许参数转化是否能够装配。

最后，如果抓取模块不是从web上来，而是从其它地方来（比如数据库），是否容易就此做一个小组件把功能动态替换掉。这种独立性和动态性从何而来认真思考下，只是因为他们用了相同的接口吗？他们不需要沟通就能做出来彼此能够结合的模块的根本原因是什么？原先固化在代码的依赖被解除后静态语言变得如此动态的原因又是什么？

我给你我的解答：这个模块需要一套输入，设计为一个iprocessor，输入一个key（url），返回一个ilistableresource，resource里面全是key（可以下钻检索）和value（文本内容）。需要一个输出iresource（为何不需要listable？），将关键字统计后作为key，count作为value放入该resource。
你回头看看你的下属做的模块跟这个差别有多大。
【 在 blackhill 的大作中提到: 】
: 共识接口，和微服务插件化
: 总结的对么？
: 看里面从哲学的角度探讨了大量问题，但感觉并没有从根本上去解决，看的粗略，妄谈见谅。
: ...................
--
修改:jekler FROM 221.217.52.*
FROM 221.217.52.*