softskillsarealwayshardthanhardskills .软技能比硬技能难。
听说老板最近很流行“微服务”，于是问架构师要不要来套我们的系统。 老板又听说最近“中台系统”很流行，问设计师我们来做吧？ 其实，这些问题不用问上司，关注技术发展趋势的设计者每次听到新技术或解决方案时，都会暗中考虑是否应用于系统。 但是，用还是不用，凭感觉是分不清的吧。 此时，如果能活用hhdbh定律的话，判断就会变得更完美。
HDBH定律hhdbh定律是马尔文hhdbh1967提出的。 “设计系统的体系结构取决于产生这些设计的组织的交流结构。 ”一般而言，产品必然是该组织沟通结构的缩影。
部门之间的交流非常困难，系统各模块的界面也反映了信息流和协作的方式。
hhdbh定律可以说是软件体系结构设计中的第一定律。 最初只是在杂志上发表，经过《人月神话》这个软件业圣经的引用，被命名为hhdbh定律(Conway’slaw )并推广。
单纯的说明可能无法理解hhdbh定律的精髓，但原文中hhdbh定律可以归纳为四个定律：
第一定律组织的交流方式通过系统设计表现出来。 第二定律时间再多也不完美，但总是有时间做完一件事。 第三定律线性系统和线性组织结构之间存在潜在的异质同态特性。 第四定律大的系统组织总是比小的系统有分解的倾向。 第一定律Communication dictates design。
组织的交流方法决定系统设计。
该规律侧重于组织结构和沟通对系统设计的影响。 组织沟通与系统设计之间有密切的联系，特别是在复杂的系统中，只有解决好人与人之间的沟通，才能更好地进行系统设计。
《人月神话》中总结了随着人员的增加交流成本呈指数函数增长的规律。 交流成本=n(n-1 )/2。 让我举例说明：
5人项目团队，需要沟通的渠道为5 * (51 )/2=1015人项目团队，需要沟通的渠道为15 * (151 )/2=10550人项目团队，沟通225150人的项目团队，需要沟通的团队沟通问题带来了系统设计的问题，进而影响整个系统的开发效率和最终产品的结果。
第二定律thereisneverenoughtimetodosomethingright，butthereisalwaysenoughtimetodoitover。
时间再多也不完美，但总是有时间做完一件事。
人手永远不够，事情永远不会结束，但可以一个个来。 这不是软件业的“敏捷开发”模式解决了的问题吗？ 面对这种情况，敏捷开发可以进行迭代、持续交付、快速验证和反馈，持续改进。
再牛的开发也能写错误，再全面的测试覆盖率也无法衡量所有的问题。 解决方案不是消灭这些问题，而是容忍一些问题的存在，并在出现问题时通过适当的设计(冗馀、监控和高可用性设计)快速解决。
几家开发者小公司，追求微服务，追求中台架构就是追求完美吗？ 不，我想死。
好的框架不是买来的，也不是设计的，而是随着业务的落地而长期演进的。
第三定律thereisahomorphismfromthelineargraphofasystemtothelineargraphofitsdesignorganization。
线型系统和线型组织结构之间具有潜在的异质同型特性。
该定律是第一定律的具体应用。 想象一下，如果公司的组织结构就是这样，团队是分散的，每个团队都包含产品、研发、测试、运输等职责。 这时只有一个系统，项目沟通和协调的成本巨大，弄不好还会吵架。
将单个系统划分为微服务器，每个团队负责自己的部分，对外提供对应的接口即可，互不干扰。 系统效率提高。 这与软件设计中的高凝聚、低耦合是共通的。
坦率地说，就是想要什么样的系统，有什么样的团队，建立什么样的系统。 如果需要前后端分离的系统，可以构建前后端分离的队伍，相反，如果前后端具有分离的队伍，可以设计前后端分离的系统。 当然，如果您有权统一管理、重组团队或设计系统体系结构，那再好不过了。 通常将两者设为1:1的映射关系，使其更有效率。
第四定律thestructuresoflargesystemstendtodisintegrateduringdevelopment，qualitativelymoresothanwithsmallsystems。
大系统组织总是比小系统更倾向于分解。
“要说天下大势，久而知之必合，久而知之必合。 ’系统越复杂，越需要增加人手，人手越多，交流成本也呈指数级增长。 那是大多数企业选择的解决方案。 分为不同级别，不同小团队，团队内部完成自我管理，然后统一对外沟通。
框架不仅需要技术，大企业特别需要政治，也就是所谓的框架
政治。眯眯眼的柠檬老师曾在他的文章《每个架构师都应该研究下hhdbh定律》中提到：“政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。”
原文链接：《hhdbh定律，作为架构师还不会灵活运用？》
程序新视界关注程序员的职场生涯，大量优质学习资源、技术文章分享