vlambda博客
学习文章列表

接触到”康威定律“，首先是在MartinFowler的那篇微服务架构的文章里，当时并没有太以为然，觉得这个引用是不是有点牵强。再到后来，InfoQ的技术会议、上周末的金融信息服务会议上都陆续有大牛们拿出来不断阐述，这时引发思考并开始接受这个概念了。所以放在这里，和大家一起分享。

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说，你想要什么样的系统，就搭建什么样的团队。如果你的团队分成前端团队，Java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

相反，如果你的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构：

而微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

反过来想，如果一个团队的组织结构并没有按照康威定律进行微服务改造，就开始着手微服务开发，最终设计出来的系统会不会还是原来的套路？这是个问题。

再来看看下面的图片，再想想Apple的产品、微软的产品设计，可能更为形象生动地理解所谓的“康威定律”。

所以，问题就来了：

这个话题其实比较大，我有点Hold不住，就先聊到这儿了，希望能给大家带来一些思辨的议题。如果各位童鞋还想深入探讨，我这儿还有些材料可以分享，比如康威定律的4个分论点。。