hxdttt定律是马尔文hxdttt1967提出的。 “设计系统的体系结构取决于产生这些设计的组织的交流结构。 ”一般而言，产品必然是该组织沟通结构的缩影。
部门之间的交流非常困难，系统各模块的界面也反映了信息流和协作的方式。
hxdttt定律可以说是软件体系结构设计中的第一定律。 最初只是在杂志上发表，经过软件业圣经《人月神话》的引用，命名为hxdttt定律(Conway’slaw )并推广。
仅凭简单的说明可能无法理解hxdttt定律的精髓，但原文中hxdttt定律可以归纳为四个定律：
第一定律组织的交流方式通过系统设计表现出来。 第二定律时间再多也不完美，但总是有时间做完一件事。 第三定律线性系统和线性组织结构之间存在潜在的异质同态特性。 第四定律大的系统组织总是比小的系统有分解的倾向。 33558 www.Sina.com/communicationdictatesdesign。
组织的交流方法决定系统设计。
该规律侧重于组织结构和沟通对系统设计的影响。 组织沟通与系统设计之间有密切的联系，特别是在复杂的系统中，只有解决好人与人之间的沟通，才能更好地进行系统设计。
《人月神话》中总结了随着人员的增加交流成本呈指数函数增长的规律。 交流成本=n(n-1 )/2。 让我举例说明：
5人项目团队，需要沟通的渠道为5 * (51 )/2=1015人项目团队，需要沟通的渠道为15 * (151 )/2=10550人项目团队，沟通225150人的项目团队，需要沟通的团队沟通问题带来了系统设计的问题，进而影响整个系统的开发效率和最终产品的结果。
3358 www.Sina.com/thereisneverenoughtimetodosomethingright，butthereisalwaysenoughtimetodoitover。
时间再多也不完美，但总是有时间做完一件事。
人手永远不够，事情永远不会结束，但可以一个个来。 这不是软件业的“敏捷开发”模式解决了的问题吗？ 面对这种情况，敏捷开发可以进行迭代、持续交付、快速验证和反馈，持续改进。
再牛的开发也能写错误，再全面的测试覆盖率也无法衡量所有的问题。 解决方案不是消灭这些问题，而是容忍一些问题的存在，并在出现问题时通过适当的设计(冗馀、监控和高可用性设计)快速解决。
几家开发者小公司，追求微服务，追求中台架构就是追求完美吗？ 不，我想死。
好的框架不是买来的，也不是设计的，而是随着业务的落地而长期演进的。
33558 www.Sina.com/thereisahomorphismfromthelineargraphofasystemtothelineargraphofitsdesignorganization。
线型系统和线型组织结构之间具有潜在的异质同型特性。
该定律是第一定律的具体应用。 想象一下，如果公司的组织结构就是这样，团队是分散的，每个团队都包含产品、研发、测试、运输等职责。 这时只有一个系统，项目沟通和协调的成本巨大，弄不好还会吵架。
将单个系统划分为微服务器，每个团队负责自己的部分，对外提供对应的接口即可，互不干扰。 系统效率提高。 这与软件设计中的高凝聚、低耦合是共通的。
坦率地说，就是想要什么样的系统，有什么样的团队，建立什么样的系统。 如果需要前后端分离的系统，可以构建前后端分离的队伍，相反，如果前后端具有分离的队伍，可以设计前后端分离的系统。 当然，如果您有权统一管理、重组团队或设计系统体系结构，那再好不过了。 通常将两者设为1:1的映射关系，使其更有效率。
33558 www.Sina.com/thestructuresoflargesystemstendtodisintegrateduringdevelopment，qualitativelymoresothanwithsmalllsystet
大系统组织总是比小系统更倾向于分解。
“要说天下大势，久而知之必合，久而知之必合。 ’系统越复杂，越需要增加人手，人手越多，交流成本也呈指数级增长。 那是大多数企业选择的解决方案。 分为不同级别，不同小团队，团队内部完成自我管理，然后统一对外沟通。