康威定律和系统设计

康威定律　任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。

松耦合组织和紧耦合组织

紧耦合组织的一个例子是商业产品公司,他们的员工都在一起工作,并有着一致的愿景和目标;而松耦合组织的典型代表是分布式开源社区。

组织的耦合度越低,其创建的系统的模块化就越好,耦合也越低;组织的耦合度越高,其创建的系统的模块化也越差。

服务所有权

服务所有权意味着拥有服务的团队负责对该服务进行更改。只要更改不破坏服务的消费者,团队就可以随时重新组织代码。

一个小团队更容易负责一个小服务。所有权程度的增加会提髙自治和交付速度。

服务会根据业务领域,而不是技术进行建模。如果负责某个微服务的团队与业务领域相匹配,则它更容易保持对客户的关注,也更容易进行以特性为导向的开发,因为它对服务相关的所有技术有一个全面的了解并且拥有所有权。

内部开源

标准的开源项目中,一小部分人被认为是核心提交者,他们是代码的守护者。如果你想修改一个开源项目,要么让一个提交者帮你修改,要么你自己修改,然后提交给他们一个pull请求。核心的提交者对代码库负责,他们是代码库的所有者。在组织内部,这种模式也可以很好地工作。

核心团队需要对更改有某种程度的审批。它需要确保所有的更改符合该代码库的惯例,也就是遵循跟代码库其他代码一致的编码准则。因此,做审批的人不得不花时间在提交者身上,以确保得到高质量的更改。好的守护者会花费大量的精力与提交者进行清晰的沟通,并对他们的工作方式进行引导。

成熟

服务越不稳定或越不成熟,就越难让核心团队之外的人提交更改。在服务的核心模块到位前,团队可能不知道什么样的代码是好的,因此也很难知道什么是一个好的提交。在这个阶段,服务本身正处于快速变化的状态。

限界上下文和团队结构

我们以限界上下文来定义服务的边界。因此,我们希望团队也与限界上下文保持一致。这有很多好处。首先,团队会发现它在限界上下文内更容易掌握领域的概念,因为它们是相互关联的。其次,限界上下文中的服务更有可能发生交互,保持一致可以简化系统设计和发布的协调工作。最后,在交付团队与业务干系人进行交互方面,它有利于团队与此领域内的一两个专家创建良好的合作关系。

转载请注明：转载自srzyhead的博客(https://srzyhead.github.io)

本文链接地址: 微服务设计 (10-康威定律和系统设计)