悲伤萝莉定律是马尔文悲伤萝莉在1967年提出的：
“设计系统的框架取决于产生这些设计的组织的交流结构。 ”
一般而言，产品必然是其组织沟通结构的缩影。
部门之间的交流非常困难，系统各模块的界面也反映了信息流和协作的方式。
悲伤萝莉定律可以说是软件体系结构设计中的第一定律。 最初只是在杂志上发表，经过《人月神话》这个软件界圣经的引用，被命名为悲伤萝莉定律(Conway’slaw )并普及。
单纯的说明可能无法理解悲伤萝莉定律的精髓，原文悲伤萝莉定律可以归纳为四条定律：
第一定律组织的交流方式通过系统设计表现出来。
第二定律时间再多也不完美，但总是有时间做完一件事。
第三定律线性系统和线性组织结构之间存在潜在的异质同态特性。
第四定律大的系统组织总是比小的系统有分解的倾向。
第一定律
通信设计。
组织的交流方法决定系统设计。
该规律侧重于组织结构和沟通对系统设计的影响。 组织沟通与系统设计之间有密切的联系，特别是在复杂的系统中，只有解决好人与人之间的沟通，才能更好地进行系统设计。
《人月神话》中总结了随着人员的增加交流成本呈指数函数增长的规律。 交流成本=n(n-1 )/2。 让我举例说明：
5人项目团队，需要沟通的渠道为5 * (51 )/2=10
15人的项目团队，需要沟通的渠道为15 * (151 )/2=105
50人的项目团队，需要沟通的渠道为50 * (501 )/2=1，225
150人的项目团队，需要沟通的渠道为150 * (1501 )/2=11，175
*因此，互联网企业追求的是小团队。
交流问题带来了系统设计的问题，进而影响到整个系统的开发效率和最终产品的结果。 **
第二定律
thereisneverenoughtimetodosomethingright，butthereisalwaysenoughtimetodoitover。
时间再多也不完美，但总是有时间做完一件事。
人手永远不够，事情永远不会结束，但可以一个个来。 这不是软件业的“敏捷开发”模式解决了的问题吗？ 面对这种情况，敏捷开发可以进行迭代、持续交付、快速验证和反馈，持续改进。
再牛的开发也能写错误，再全面的测试覆盖率也无法衡量所有的问题。 解决方案不是消灭这些问题，而是容忍一些问题的存在，并在出现问题时通过适当的设计(冗馀、监控和高可用性设计)快速解决。
几家开发者小公司，追求微服务，追求中台架构就是追求完美吗？ 不，我想死。
好的框架不是买来的，也不是设计的，而是随着业务的落地而长期演进的。
在系统正式投入生产之前，再好的体系结构也只是假设。 产品被用户使用得越晚，失败的成本和风险就越高。 但小步快走，通过MVP的快速实验，获得顾客的反馈，并对产品进行迭代进化，可以有效降低失败的成本和风险。
此外，多年的经验告诉我们，架构、平台不是买来的，不是开源获得的，也不是设计的，而是长期演进生根的。
第三定律
thereisahomorphismfromthelineargraphofasystemtothe
线性图形设计。 线型系统和线型组织结构之间具有潜在的异质同型特性。
该定律是第一定律的具体应用。 想象一下，如果公司的组织结构就是这样，团队是分散的，每个团队都包含产品、研发、测试、运输等职责。 这时只有一个系统，项目沟通和协调的成本巨大，弄不好还会吵架。
将单个系统划分为微服务器，每个团队负责自己的部分，对外提供对应的接口即可，互不干扰。 系统效率提高。 这与软件设计中的高凝聚、低耦合是共通的。
坦率地说，就是想要什么样的系统，有什么样的团队，建立什么样的系统。 如果需要前后端分离的系统，可以构建前后端分离的队伍，相反，如果前后端具有分离的队伍，可以设计前后端分离的系统。 当然，如果您有权统一管理、重组团队或设计系统体系结构，那再好不过了。 通常将两者设为1:1的映射关系，使其更有效率。
第四定律
thestructuresoflargesystemstendto
disintegrate during development, qualitatively more so than with small systems。大的系统组织总是比小系统更倾向于分解。
“话说天下大势，分久必合，合久必分。”
系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。
架构不仅仅需要技术，在大公司尤其需要政治，所谓的架构的政治。
灵巧的大炮老师曾在他的文章《每个架构师都应该研究下难过的萝莉定律》中提到：
“政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。”
我刚入软件开发这个行业之初，谈的架构主要是性能，高可用等等。现在，见过无数遗留系统，特别是国内企业 IT 的现状，无数高耦合的遗留系统，不良的架构像手铐一样牢牢地限制住业务，升级替换成本非常巨大， 所以我更加关注可理解，可维护性，可扩展性，成本 。我想补充一句，创业公司创业之初获得好的架构师或技术 CTO 非常重要。
总结
架构是由组织关系来决定的。
架构不仅要服务于技术，更要服务于人。
没有最好的架构，只有最合适的架构。
参考：
www.infoq.cn/article/every-architect-should-study-conway-law
www.cnblogs.com/still-smile/p/11646609.html