第一定律
组织沟通方式决定系统设计
说明：这条定律重点是讲组织架构和沟通对系统设计的影响。组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。
简要概括：跨部门的的沟通协作是比较复杂，系统设计的好坏也取决于好的沟通，沟通不好容易扯皮
软件方面的思考
1.好的模块设计，能有效的解决跨模块间的相互调用，职责更加单一，如何把控边界是一个问题
2.尽量减少跨模块间职责的不单一
3.如果职责不够单一，一个模块里带有其它的模块的功能，那么会造成一些资源的浪费，比如：某个功能的请求量大，但其它功能的请求量不大。
第二定律
时间再多一件事情也不可能做的完美，但总有时间做完一件事情
说明：人手永远是不够的，事情永远是做不完的，但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况，敏捷开发可以做到不断迭代、持续交付、快速验证和反馈，并持续改进。
简要说明：敏捷开发、快速迭代、持续交付、快速验证和反馈，并持续改进
软件方面思考
1.把任务拆细了，两周一个小迭代
2. 通过持续迭代把每个功能模块保质保量做好
3.BUG是改不完的，可以容忍问题的存在，通过设计、高可用、监控、等手段进行解决
第三定律
线型系统和线型组织架构间有潜在的异质同态特性
说明：这一定律是第一定律的具体应用。想象一下如果公司的组织架构是这样的：团队是分布式，每个团队都包含产品、研发、测试、运维等角色。而此时系统是单块的，项目沟通和协调的成本是巨大的，弄不好还会打起来。
简要思考
团队包含产品、研发、测试、运维等角色，一个敏捷的团队
软件方面思考
1.在一个团队组织中包含各个角色，管理、协作、沟通比较方便
2.以微服务为例：每个模块子系统都有独立的团队负责，效率开发将大大提升
第四定律
大的系统组织总是比小系统更倾向于分解
说明：“话说天下大势，分久必合，合久必分。”系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。
简要思考：将大系统拆成独立职责单一的小系统，每个小系统有独立的团队负责，从而减少沟通成本
