康威定律和系统设计
康威定律:
任何组织在设计一套系统时,所交付的设计方案再结构上都与该组织的沟通结构保持一致。
1.证据
1.1 松耦合组织和紧耦合组织
松耦合组合和紧耦合组织。紧耦合组织的一个例子是商业产品公司,他们的员工都一起工作,并有着一致的愿景和目标;而松耦合组织的典型代表是分布式
开源社区。组织的耦合度越低,其创建的系统的模块化就越好,耦合也低;组织的耦合度越高,其创建的系统的模块化也越差。
1.2 Windows Vista
2.Netflix和Amazon
两个披萨团队:没有一个团队应该大到两个披萨不够吃。
3.我们可以做什么
4.适应沟通途径
一个简单的团队可以进行频繁,细粒度的沟通。服务内部是大量细粒度的方法和函数调用。服务内的变化的频度远远高于服务间的变化。
物理位置不在一起的团队,只能依靠粗粒度的沟通。
5.服务所有权
服务所有权:它意味着拥有服务的团队负责对该服务进行更改。只要更改不破坏服务的消费者,团队就可以随时重新组织代码。把决定权交给合适的人,赋予团队更多
的权利和自治。
6.共享服务的原因
6.1.难以分割
拆分服务的成本太高是多个团第负责单个服务的原因之一。
6.2.特性团队
一个小团队负责开发一系列特性需要的所有功能。这种结构促使团队保持关注在最终结果上,并确保工作是集成起来的,避免了跨多个不同的团队视图协调变化的挑战。
在许多情况下,特性团队是对传统的IT组织中,团队结构围绕技术边界进行组织的一种修正。
什么是微服务:服务会根据业务领域,而不是技术进行建模。如果负责某个微服务的团队与业务领域相匹配,则它更容易保持对客户的关注,也更容易进行以特性为导向
的开发,因为它对服务相关的所有技术有一个全面的了解并有用所有权。
6.3.交付瓶颈
共享服务的另外一个关键是,这样做可以避免交付瓶颈。不共享服务,我们有几种方式来应对。第一种是等待。另外一种是,你可以派人到缺人的团队工作。
7.内部开源
如果我们已经尽了最大的努力,仍然无法找到方法来避免共享几个服务该怎么办?这个时候,拥抱内部开源模式可能更合理。
标准的开源项目中,一小部分被认为是核心提交者,他们是代码的守护者。
7.1 守护者的角色
我们在内部也要采用跟标准开源项目同样的模式。这需要分离出一组受信任的提交者(核心团队)和不受信任的提交者(团队外提交变更的人)。核心团队需要对更改拥有
某种审批,它需要确保所有的更改符合该代码库的惯例。
7.2 成熟
大多数开源项目在完成第一个版本的核心代码前,往往不允许让更广泛的不受信任的提交者们提交代码。
7.3 工具
8.限界上下文和团队结构
我们以限界上下文来定义服务的边界。因此,我们希望团队也跟限界上下文保持一致。这有很多好处,首先,团队会发现它在限界上下文更容易掌握领域的概念,因为它们是
互相关联的。其次,限界上下文中的服务更有可能发生交互,保持一致可以简化系统设计和发布的协调工作。最后,在交付团队与业务干系人进行交互方面,它有利于团队与此
领域内的一两个专家创建良好的合作关系。
9.孤儿服务
那么如何处理不再活跃维护的服务呢?当我们迈向更细粒度的架构时,服务本身变得更小。小服务的目标之一是使它们更简单,功能较少的简单服务,可能在很长的一段时间内
都不需要修改。
10.案例研究:RealEstate.com.au
11.反向的康威定律
12.人