Balancing Coupling in Software Design with Vlad Khononov
50:00 Share

寻找刺激，巨型赌场已在此等候。随时随地玩，在火车上玩，在商店玩，在家玩，在你的板上玩，今天玩，有机会赢取奖金，每日登录即可免费玩。体验前所未有的游戏乐趣，现在就进入ChAmbers，玩数百款游戏，包括在线游戏、大量俚语等等，在ChAmber Casino 点 com体验ChAmber生活。煽动性地吃掉阶级。

黑色星期五就要来了。对于你生活中热爱最酷玩具的成年人来说，今年也有适合他们的东西。Martin是首屈一指的手工鸡尾酒调酒师，它会自动制作超过六十种季节性和经典鸡尾酒。

只需按一下按钮即可获得三十秒。现在，但教学正在进行大规模销售周期。当您额外花费四百美元时，您可以获得任何鸡尾酒制作或鸡尾酒笔的百美元。如果您生活中热爱鸡尾酒的人今年表现良好，所有正确类型的糟糕，只需按一下按钮即可获得茶，制作高质量的Cosmopolis、Marti、曼哈顿等，所有这些都在短短三十秒内完成，所有这些令人惊叹的玩具都只是为孩子们准备的。在星期一访问关于教学的网站，花费四百美元即可获得百美元的鸡尾酒机，访问aboutteaching.com，闪耀鸡尾酒，访问BARTESIAN.com，闪耀鸡尾酒。

你喜欢如何收听没有广告的网络摇滚吗？简单。只需每月五美元即可成为赞助商。

您可以访问一个私人RSS源，所有节目都没有广告。二十美元将获得该终端，一个特殊的netrocks赞助商马克杯。立即访问patron.netrocks.com注册。

嘿，欢迎回到netrocks。我是卡尔·弗兰克林。

我是理查德·坎德尔。

我们在这里为您提供netrocks的乐趣。

以及您想要的任何其他乐趣。但是，你知道，不要发疯。不。

我将限制。

到netrocks，可以吗？

也许是科技带来的乐趣，也许是少许科学。是的。

我说的没错。我的年度科技狂欢，伙计们。这工作量很大，但我正在努力完成。

太好了。我迫不及待地想，迫不及待地想听到他。好的，让我们开始我们称之为“更好地了解框架”的小事。

好的。

所以我开始寻找在sea-sharper、posit或github方面最热门的东西。最近活动很多或很酷的一个是汤姆·赫斯特的TeaUnit，一个现代、快速且易于使用的.NET测试框架。我现在还没有使用过它。

除了它在reao中所说的内容外，我对它一无所知，那就是它是一个现代且快速的TeaUnit，它利用源代码生成器来定位和注册。您的测试与反射相反。不错。

在构建时间和运行时速度方面，您将获得构建时间的睡眠提升。TeaUnit还在于新的Microsoft测试平台。就像Microsoft.Testing平台一样，您将不得不使用其他框架，您将使用VS测试。该新平台从头开始重建，以解决痛点，使其更具可扩展性，并且更快。

所以这只是在xUnit上运行，但执行取决于反射。在这里，他们使用分析器系统，是的，某种现代化的扭曲，是的，就像我说的那样。

它很热门，你可能想看看它。这就是我找到理查德的时候。

今天和我们聊的是谁，格拉B2Come到eve r sho wed nin eteen，sixteen。所以这是我们在九月展示的渲染回放，我称之为尽可能简单，对吧？我的意思是，这个人聪明，对吧？就像真正有条理地思考开发，以及我们如何以正确的方式做正确的事情，他启动了自主性评论，很多人对这个节目做出了反应。

现金宝说，他说，这是一个非常有趣的展示。如果他的写作讨论与我们目前在工作中与八名开发人员团队进行的讨论类似，所以规模远不及Netflix。

X，没问题，伙计们。你不用决定。Netflix的问题很多。我们正在构建大量微服务，因为我们可以。这很好，但代价很高。一个例子是，我们正在使所有内容都同步，即通过主题和队列的形式进行服务总线集成。

同样，四月一切都很好，因为每次我们进行服务之间的通信时，我们的微服务非常小，我们都会遇到事情无法按预期运行的情况，最终出现在D、L、Q中。有人或某物必须监控和补偿。突然间，我们开始构建点和句柄，允许消息被修复和重新运行。

所以我们花宝贵的时间来创建补偿体系，以弥补架构和基础设施问题，而不是真正构建业务价值，对吧？我的意思是，在架构中，一条简单的直线最终可能会变得极其复杂。另一个有趣的事情是，我们开始使用鹿。

这是D、A、P、R，其原因与曼德尔提到的原因完全相同。最终，我们再次放弃了它，结果发现它是一个糟糕的开发体验。Dep是另一个很好的例子，从架构的角度来看，这是一个好主意，但实施起来却是一场噩梦。

未来肯定会改进。但从开发人员的角度来看，它太成熟了。感谢精彩的节目。我总是觉得在您有租赁时，我正在喝茶和吃饼干。

或者更像鱼和薯条和斯托特，而且。

怀疑，和平，当然，是的，你可以继续知道你已经走上了这条路，你看到了周围所有事情的挣扎。同样，这就像因为你可以思考问题，现在架构会很有趣，而且不应该那么困难。

你已经完成了分离关注点的艰苦工作，现在你想把一些东西重新组合在一起，但听到正在进行的实验和他们面临的挑战很棒。你们团队很大。我的意思是，八个人足够了，足以让工作坊变得相当冷清。所以现金，非常感谢你。如果你想喝一杯咖啡，请在网站上发表评论，在netrocks上发表评论，在我们的Facebook页面上发表评论，我们会在那里发布每个节目，如果你在节目中发表评论，我会想办法给你一杯咖啡。

或者如果你想购买音乐代码，你可以通过netrocks访问音乐代码，你也可以关注我们的Twitter。当然，我们已经做了很多年了，但酷孩子们正在聚会。我掌握了。

我在卡尔·弗兰克林的推特上，有社交媒体，我叫理查德·坎德尔。

让我们把麦克风交给理查德。在我们开始之前，我意识到我还没有完成我的，你知道1923年发生了什么吗？

这是第20集。

我们必须这样做，因为我们通常访问的页面由于某种原因无法访问。但只是选择一些。1月5日，生活赢家开始了剪刀起义，以应对客户区域。

我不知道。我知道这很像第二次世界大战，对吧？所以你谈论的是四种自动帝国崩溃的方式，这绝对很疯狂。

3月1日，非洲最大的电力生产商Econ在南非成立。3月3日，时代杂志的第一期出版。哇，让我们继续。

3月9日，约翰·列侬遭受了第三次中风，这使他卧床不起，无法说话。因此，他辞去了苏联政府主席的职务。让我们看看5月英国首相鲍恩·博恩因健康状况不佳而辞职。

我知道，哦，爱尔兰内战于5月24日结束。让我们看看我还能找到什么。7月10日，苏联罗斯托夫地区的巨大冰雹杀死了23人。

哦，我的天哪。那是巨大的冰雹杀死了人。是的。

就像20人被刺杀一样。他的狗，阿波罗。卢根条约签署，确定了土耳其共和国的边界，对吧？我会说23年最重要的。

事情是啤酒推。这是希特勒和他的党卫军首次尝试推翻巴伐利亚政府的开始吗？

在11月8日，慕尼黑的阿道夫·希特勒领导的纳粹党试图推翻巴伐利亚政府，警察和军队挫败了他们的企图。第二天，有20人死于相关的暴力事件，我们的朋友克里斯蒂安·维尔还没有出生。

不，但他确实，你知道。人们会争论当时该党缺乏后果。为后来发生的事情埋下了伏笔。

是的，我不知道你为什么要提到这个。你指的是某种事件或什么吗？

我没有提到任何事情，我提到的是事情。我不知道你在说什么。

我也不知道你在说什么。好的。好的，让我们请来我们的嘉宾弗拉德。弗拉德是一位经验丰富的软件架构师。他曾担任过从网站管理员到首席架构师等各种职位，目前帮助组织理解他们的业务领域，解开单体应用程序，并解决复杂的架构挑战。

2021年，弗拉德出版了《学习领域驱动设计》，随后是他的最新著作《软件设计中的耦合平衡》，于本月早些时候作为公开演讲者出版。弗拉德在世界各地的会议上发表演讲，主题包括软件架构、领域驱动设计和分布式系统。我相信这是他第一次在netrocks上露面。

所以欢迎你，弗拉德。非常感谢你。这真是。

你听说过我们的。

节目，是的，我相信我从2006年开始收听你们，然后你们毁了我听其他播客的体验，因为没有达到预期的质量。

从其他节目中。

我们一直非常认真地对待节目的工程方面。是的，我们的内容更有趣，但高质量的音频很重要。

内容质量在理查德加入团队后大幅提升。

当然。这已经持续了很长时间，感觉就像几个月前就过去了二十年。

是的，是的。还记得我们之前在您加入之前进行的系列节目吗？我们开始做喜剧和两小时的节目。我们当时在想什么？

那是一个杂技节目。还记得我们谈论过这个吗？所以这里有一个图表。

这里有一个技术面试人员和想要音乐、笑话和所有这些东西的人的图表。交集很小，但其他两个大圆圈很大。为什么我们只是分开？对吧。所以有一天，路演变得更大。

好的，弗拉德，关于我们的话就到这里。让我们谈谈你解开单体应用程序并平衡复杂性的经验，对吧？你在说什么？

是的。实际上，理查德的经历听起来与几年前我经历的经历很相似。我们也有一个正在运行的系统，正在产生业务价值。

但它是一个单体。它是一个单体冷启动。所以他说，好的，让我们通过将其分解成微服务来改进它。换句话说，让我们解耦事情。所以我们引入了许多我们称之为微服务的微服务，当然，它们之间有六种集成。从那时起，该系统就无法演变了，无法更改，因为我们突然必须修改这些服务中的很多个，或者我不想说微服务，因为它们与微服务无关。是的，我不知道该怎么称呼它。

我的意思是，你如何称呼它，只有在评论中提到它时才是微服务？我不知道区别，它只是服务。

是的，它们完全分离，对吧？但我认为我们谈论的，以及我们一直在谈论的，是它的复杂性方面，当你想要实现一个功能时，你必须接触到很多不同的位置，以确保它仍然强大。

是的，是的。同样，我从分解事物开始，以实现解耦。但我们所做的是增加了耦合。

现在一切都耦合在一起，如果以前我们只需要修改一个代码库，现在我们必须修改多个项目，然后同步更改。这有生命周期，有很多乐趣，但这是致命的，灾难性的失败。我的意思是。

另一种选择是运行每个服务的多个版本。我已经走过这条路，就像，嘿，如果我们更改C、P、I，我们将影响其他事物，就像，好的，让我们让旧的运行，但同时运行新的。

让我们有一个服务，返回所有正在运行的服务的当前版本。

这根本不是问题。一切都很好。它。

如果你在该服务中遇到合并冲突，版本服务服务服务服务，哦，我的天哪。

但是，你知道，我觉得你是在用单体问题来交换微服务问题。这里没有免费的午餐。是的。

绝对。平衡在哪里？因为我知道它在标题中。

是的。在经历了该项目的灾难性失败之后，我想弄清楚微服务是什么，如何正确设计它们的边界。我在一本出版于7月份的书中找到了我正在寻找的答案，它被称为结构化设计。答案在耦合中。

并且在其中，我发现了一些过去行业中有趣的东西，但我们现在似乎忘记了。所以我所做的是，我想做的是将这些被遗忘的见解应用于我们当今的技术世界，以及我们今天正在使用的技术。这就是耦合平衡模型的诞生。

这里的想法是，每当你有两个组件时，这些组件可以是任何东西，无论是服务、微服务还是类，相互交互以协同工作，它们必须交换一些关于彼此的知识，例如，你的公共接口是什么？我必须传递的数据格式是什么？或者，也许我必须对你的行为做出哪些假设？所以让我们称之为知识。

第二个方面是它们之间的距离。如果我们谈论的是两个类，那么它们的代码位于附近。它们可能在同一个文件中，在同一个目录中，用相同的语言。

另一方面，如果我们谈论的是微服务，那么这些源代码调用之间会有更大的距离，对吧？更大的距离。

为什么我们应该对它感兴趣？距离越大，协作和沟通的努力就越多。你需要实施一个影响两者的更改。所以我要回到评论中的那个例子。

一旦你将单体分解成微服务，你就会增加系统中这些部分、这些组件之间的距离。现在它们位于不同的微服务中。所以我们有更大的距离。

当我们观察这两个维度时，一方面是它们需要共享的知识，另一方面是它们之间的距离。然后，通过评估它们的极端组合，我们可以得出一些有趣的见解。例如，如果在较大的距离上进行大量的知识交流，那么结果就不会正确。

它们共享的知识越多，随之而来的更改案例就越多，更改的理由就越多。这些组件将一起更改。现在，当你将增加的距离与之结合起来时，我们就需要进行大量的更改，并且需要付出大量的努力来实施这些更改。

总而言之，这不好。是的。或者我们可以看看它的反面。

如果我们有两个共享知识很少的组件呢？也许它们甚至没有集成，只是位于彼此附近。因此，它们之间的知识和距离都很低。

现在我们拥有的组件彼此之间并没有真正的关系。它们位于同一个代码库中，相同的命名空间，相同的包模块（无论你如何称呼），这通常被称为经典的模块或一大堆无关紧要的东西。它们彼此靠近，但彼此无关。

下次你需要修改某些内容时，你必须遍历这些内容，才能找到需要修改的类或模块。在这两种关系中，距离远，强度高，知识多，我称之为知识集成强度维度。因此，一旦你拥有高集成强度和高距离，你就会在整个系统中遇到复杂性。

如果知识为零，距离也为零，那么你又会遇到另一种复杂性？你将面临认知负荷，因为你需要努力理解正在发生的事情。哪些东西在同一个模块中实现？当新的业务需求出现时，你是否需要修改它们？所以这些是两种类型的复杂性。

现在，如果我们反转这些关系呢？如果我们查看低集成强度，这意味着在较大的距离上共享的知识量少？较大的距离意味着我们仍然需要投入大量精力来实施更改。

另一方面，我们有低集成强度。因此，我们最大限度地减少了这些更改的可能性。并且这种关系通常被称为松散耦合。

对吧？当你调用第三方应用程序和类似的东西时，通常就是这样，对吧？它们都是松散耦合的，因为它们之间的距离很小，集成程度很低，并且它们位于较远的地方，集成程度很低。是的，它们不在你的范围内。它们拥有自己的状态，你不能依赖任何外部的东西。

来问问题。

得到任何答案，是的。反之，将是高集成强度，在较小的距离上共享大量知识，对吧？现在，我们确实希望最大限度地减少我们在组件边界上共享的知识，当然，但这并非总是可能的。有时我们确实需要共享知识，因为也许有两个组件正在实现密切相关的业务功能。所以我们必须共享。

现在，也许它们都在注入相同的服务。

类似的事情。是的，是的。评估这种知识有不同的层次。让我们总结一下。

我们处于该量表的较高端，在这种情况下，我们无法通过将它们彼此靠近来减少知识量。我们知道我们承认这一点，但它们会一起更改。但我们正在准备应对这些情况。

通过最大限度地减少来做到这一点。是的。我的意思是，我在这里看到一个规则出现，那么，如果这两件事紧密联系在一起，我们应该确保它们靠近。

是的，是的，是的。在九十年代，提出了一个模型，一个冷连接模型。在这个模型中，根据米尔贝·琼斯的说法，使用空间接近性来表示事物应该彼此靠近。出于其他原因，我更喜欢“距离”这个词，它是“接近性”的反义词。是的，是的，但那是这样。

基本思想是，让你的微服务或任何东西都保持原样。但是，共享知识的那些应该更靠近，而那些应该有更多距离的那些应该彼此依赖性更小，知识更少。

是的，完全正确。问题是，如何评估这种知识？是的，这是复杂的部分，因为如何衡量知识？像什么是什么管理衡量？

知识的单位是什么？是的。

但我需要知道多少？是的，是的。为此，我从七十年代的《结构设计》一书中借鉴了这个模型，以区分各种类型的知识。

现在，一旦我们处理了类型，我们就不必测量确切的知识量，因为一旦我们在这个类型的量表上上升，无论如何，数量都会显著更高，对吧？总的来说，有四个基本级别。其中之一是，假设我们正在实现两个组件。假设理查德，你在实现微测试，这意味着当我使用IT时，我应该使用它的公共接口，但我不会这样做。相反，我会访问你的数据，或者快乐地获取。

任何我需要的资料。

请让坏人停止。

是的，所以我在做的就是介绍和依赖。

依赖于你的实现，并且打破了非常，并且不知道我做了什么。

是的，这就是为什么我们称这个级别为侵入式耦合。我正在包含你的边界。我的意思是。

以某种方式，这对我来说并不那么令人烦恼，因为你可以打破我，你真的不能。

打破我，这取决于我正在做什么。

就像啤酒推销一样。

我的意思是，你是对的。你可以将数据导入我的数据库。是的，你知道，可以打破我的代码，这期望数据库具有某种一致性，而我的数据库应该有参数，不允许你这样做。

是的，所以这就是侵入式耦合，这是。

最高级别的非。所以是的。

它在级别上。

一个依赖于另一个。让我们回到，好的，让我们回到下一个级别。功能耦合。在这里，我们有两个组件，它们正在实现密切相关的功能。也许它们正在实现密切相关的用例，但最重要的是，当业务需求发生变化时，它们必须一起更改。

所以他们在一起。

是的，是的。所以它们必须共享大量知识，因为一旦存在功能依赖性，我们就必须假设会有业务规则，它们两者都必须遵守。这就是功能耦合。现在，功能耦合有不同的程度。让我们不要深入探讨，因为我们只需要一个小时来讨论这个主题。

但其中一个论点是它们应该成为同一个服务，是的。

但是让我们回到。

稍后。我已经判断。

是的，第三个级别是模型耦合。这意味着我们有两个组件，它们共享它们正在使用的业务领域的模型知识。现在，每当我谈到这个级别时，我必须戴上我的领域建模和设计帽子，因为它深受领域驱动设计的影响。

问题是，当我们实现一个系统时，当然，我们不会编码所有关于该业务领域的知识，但我们必须选择我们认为对解决我们想要为系统用户解决的问题相关的知识。所以我们正在构建一个业务模型，现在有了新的需求，对业务领域的新的见解。这个模型应该随着时间的推移而演变。

一旦我们共享了这种知识，我们就降低了演变这个模型的能力。所以，在某些情况下，这可能会出现问题。这是集成强度的第三个级别。

但模型的变化不如功能变化频繁。嗯，这取决于。

你正在处理的系统类型。假设你为一家初创公司工作。在最初的阶段，有很多不确定性。

是的，关于。

关于我们如何为客户解决问题，甚至问题本身都可能发生变化，是的。这就是模型耦合，第三个级别。现在，最低级别是我称之为合同耦合的级别。在这里，我们有一个专门为集成目的而制定的集成合同。它的目标是封装所有关于实现细节的知识，旧的知识，关于功能需求的知识，当然，以及所有关于正在用于实现我们想要公开的组件的业务领域模型的知识，这是一个更稳定的接口，不会在每次出现新的业务需求时发生变化。

这是公共API接口。

心态。完全正确。是的。如果我再次戴上我的领域建模和设计帽子，那么我们有。以及我们拥有的耦合。

但是开放的宿主服务，这些服务所做的本质上是为这些目的引入了一个集成合同。所以我们有四种类型的接口，合同、模型、功能和侵入式。这些是四种类型的知识。我们无法对知识量进行数值评估，但这些四种类型已经帮助我们评估了我们的位置。是的。

请将人们正确地归类。

是的。现在，我在书中提到，功能、模型和合同耦合都有程度，这样你就可以比较相同类型的接口。如果这些程度基于坎贝尔模型，它有很多级别，所以这需要另一个主题。

四个是一个很好的数字，对吧？你可能能够区分，特别是功能级别，你可以在其中区分选项。但我认为四个，你可以对它感到满意。我不是说所有的耦合都是坏的。我承认一些耦合是必要的，但有些耦合具有更大的影响。

而另一些则与组件之间的维度空间距离有关。一方面，我们有组件实现的代码库。如果文件位于同一个目录中，则距离较小，或者甚至在同一个文件中，距离最小化，而不同于不同的存储库或进程。

但该维度还有另一个方面，即组织方面。首先，让我们假设我们有两个情况。在第一个案例中，两个微服务由同一个团队实现。

在第二个案例中，两个微服务由不同的团队实现。是的，在第二个案例中，我们需要更高的协作和沟通努力来实施更改。因此，组织也影响了距离。

我争辩说，沟通也是如此。这一个很容易，因为你们在同一个团队中，而另一个则需要更多结构，因为你们不在同一个团队中。

是的，完全正确。所以我们有组织方面增加了距离。而且，再次回到你一开始就提到的康威定律，假设我们有两个组件，它们之间存在同步通信。

在第二个案例中，它们之间存在同步通信。现在，在异步通信的情况下，它们之间的距离更大，它们之间的虚拟距离更大，让我们这么说，因为它们之间的生命周期依赖性更低，对吧？如果我们有较小的距离，例如，组件在同一个模块中实现，那么这些服务之间存在生命周期依赖性。该模块中的所有内容都必须同时实现、测试和部署。

功能耦合。是的。

一旦我们引入它们之间的通信，我们就在某种程度上增加了距离。让我们回到集成强度的主题。假设我们有两个组件，它们之间共享大量知识。

假设它们之间存在高耦合。假设它们之间存在较大的距离。这个设计是否一定是坏的？我的意思是。

它对它有很大的影响。是的，对吧？你需要大量的沟通才能移动。如果你有一个好的测试框架，它会经常失败，因为你正在移动的东西。

我想我会问，你为什么选择这个模型？哦，你需要什么？

这是一个很好的问题。我会提供更多关于上下文的资料。所以，我正在开发一个系统，它与一个法律系统集成，而这个法律系统永远不会改变。不，没有人想触碰它。所以没有人可以要求我添加一个新的接口。

到它。

这样我就可以工作了。

我正在做这件事，但我假设这个遗留系统现在不会改变。这就是耦合的第三个维度，即易变性。

我认为这是一个很好的休息时间。所以让我们先保留这个想法。弗拉德稍后会回来，在这些非常重要的信息之后。你是否知道你可以直接从你的AWS提供工具包来工作？对于Visual Studio、Visual Studio Code和JetBrains Rider，学习更多信息，请访问aws.amazon.com/net/tools。你好。

这是瑞安，我们所有人每天都需要一个额外的亮点，一个好的方式，只是为了弥补像在交通中坐、洗碗、周一数步等事情。这就是为什么我如此喜欢特朗普，一个赌场冠军。赌场是所有你最喜欢的社交赌场风格游戏。

你可以随时随地免费玩，每天都有奖励来注册。那就是冠军。赌场由Casino VG W Group运营，法律禁止。

18岁以上，适用条款和条件。

我们回来了。这是.NET Rocks。我叫弗兰克林·理查德·坎贝尔，我们正在与弗拉德·霍诺诺夫谈论耦合、耦合平衡和解耦，我想我们称之为。

平衡耦合。

是的，平衡耦合或程度。

所以你刚刚在那里引入了一个第三个维度，即易变性与距离，这并不一定是物理距离，团队是否分离？他们是否在不同的团队中？也许安全边界是不同的，有很大的分离。然后是代码内部的交互程度或耦合程度，它们联系得有多紧密。

是的，现在正在分享，所以是的。

不是他们管理的知识，以及你画的界限和区域，比如，我在我的新应用程序中对现有应用程序进行了一些耦合，它相对较近。我们正在处理相同的上下文，但易变性非常低，因为我不能更改其他代码。所以对我来说，这似乎不是最低的。这似乎是唯一的选择。

以及情况，是的，这让我们回到了该模型的名称，即平衡耦合。一旦我们有了这三个维度，一旦我们可以评估它们，我们就可以说，好的，所以我们有集成强度，我们有距离，我们必须彼此成比例。好的，好的。一旦其中一个变高，另一个就应该变低。

我们甚至可以找到一些中间立场。如果我们拥有中等数量的知识，那么中等距离也还可以。但有时我们需要，我们可以更务实一些，引入第三个维度——易变性。如果预计组件不会发生变化，那么共享知识的那些组件，允许它们在较大的距离上共享大量信息，也是可以的。

对吧？是的，而且，我们又回到了那个思路，嘿，我们发现这个之间存在很多耦合。也许我们需要把它们放在同一个团队里，如果我们把团队成员调到另一个团队，很多复杂性就会结束。

虽然这项工作正在进行中，沟通变得更容易，我们可以度过这段时期，并决定接下来会发生什么。嗯，与之相反的是，嘿，这很复杂，距离很远，我们无能为力。所以让我们尽量减少易变性。

是的，这非常有趣，因为在书中，我讨论的是软件设计。然而，我和我朋友（一个软件架构师）谈论了组织设计，结果发现我们可以用同样的模型来评估组织的设计。例如，如果团队成员在同一领域工作，但关注的是不同的后续事项，这意味着他们之间不会共享太多信息。

对吧？我为什么要……

把他们放在一个团队里？

在这里，你谈到了康威定律，这个想法是团队架构也会有效地决定软件架构。举个例子，如果你有三个团队，你就会得到一个三层架构，是的，它会如何运作，现在你正在谈论，嘿，当我们找到最佳架构时，我们可以开始塑造团队结构，这样时间就不会与我们作对。

完全同意。

这真的很有趣。你现在描述了这种情况，你可能想要添加团队成员，甚至分离团队。这两种情况都是合理的，这可能是一个非常好的案例，在两种情况下，你都能看出为什么改变组织结构。

来反映预期的结果。首先，我们修复……

架构，然后我们可能需要修复团队架构，以作为一种回馈。我们并不总是看到这两件事最终会耦合在一起，对吧？随着需求的出现，你看到越来越多的耦合，你可能会发现一个区域，嗯，好吧，我们可能应该把这些东西放在一起，但是这个参与者可能无法轻松地加入那个团队。我们是否应该调换团队成员，让其他人来处理这个问题，因为这会让所有其他事情变得更容易？是的，改变团队成员确实需要成本。但这可能比继续目前的状况更划算。

是的，正如他们所说，组织设计总是胜出的，对吧？所以我们需要一种评估在组件之间、跨团队或团队成员之间共享的信息类型的方法。

是的。

改变代码比改变人更容易。

但有时如果需要的话，改变人会更有效率。我喜欢的是，我们创造了一个进行该对话的理由。

是的，当我从平衡公司的角度考虑，以及平衡这三个因素时，其中一个选择突然变成了，我们是否应该改变团队来解决这个问题？这是否可行？因为有时这可能是一个非常容易的解决方案，例如，这个人一直想加入那个团队，现在我们有充分的理由让他们加入，至少引入了我们利用康威定律来调整团队以提高质量的想法。

这是个好想法。以我的经验，理查德，也许你也有过类似的经历，弗拉德也是，添加团队成员比移除他们更容易。

从团队中移除某人。人们不喜欢被移除。我发现……

这个人，但我同时也喜欢，你可以更独立地工作。

你不需要在这里。你知道，还有另一个团队我们希望你加入，因为你可以在那里发挥更大的作用。

比那种事情好，是的，是的，个性方面。但我只是想现在可以用一种连贯的方式把它摆在桌面上。这不是政治，也不是针对某个人。

我看到了架构中的一个问题，这将导致一些后果，也许改变团队结构可以减轻这些后果。有趣。不，我有点震惊。

我很兴奋。啊，包放平了。这真是一个很好的讨论方式。

是的，拥有一个框架来制定这类事情很重要。是的，你知道，当我决定成为程序员时，他们告诉我你会和计算机打交道，而不是和人打交道。这是最大的谎言。

结果是人使用软件，而这会毁掉一切。

现在我们可以……

摆脱这些人了。这是精神上的。

什么记忆？

你知道，只要没有人使用这个软件，它就能很好地工作。

我想知道为什么？这就是为什么会有喜欢人的前端开发人员和不喜欢人的后端开发人员。你知道，人们会变成D、B、S，因为他们只想和数据库对话。

就是这样。当我与人交谈时，我会说，不，不。

不，你可以。不，你可以。

对不起，我们跑题了。还有更多内容，继续吧。

你打开了一个盒子。团队和代码的架构必须协同工作。现在康威定律绝对适用。

是的，绝对的。两者是紧密相连的。这就是我喜欢距离这个维度的原因，即使我们只关注冷冰冰的代码，它也反映了组织设计。

所以你在咨询公司，他们有一些糟糕的设计，或者他们可能使用了微服务，无论如何，你看到了这里描述的问题。你如何让他们相信这些东西，而不显得过于学术？我的意思是，你在这里讨论的是相当技术性的东西，对吧？你有公式等等。也许你可以分享一些你处理客户的经验，以及他们如何解决这些问题。

是的。最常见的案例是，一家公司使用微服务，最终导致了模型的分布。最困难的事情是说服他们将所有内容都带回同一个代码库，随着时间的推移重新设计成模块化模型，然后重新集成到微服务中。

有趣。这似乎不是正确的路径，但我能理解为什么我会这么想。

因为一旦你将所有内容放在同一个代码库中，距离就会缩短，这意味着更容易一起更改事情。

如果你需要……

做……是的，现在你评估这些服务的边界，你想构建的微服务，一旦它们在同一个代码库中具有逻辑模块的形式，那么犯错也没关系。这正是正确的，一个很容易修复的错误。

但你也在做非常经验性的工作。你知道，如果你把它们组合在一起，它们会获得一些动力，一段时间内会更容易。但最终你可能会遇到某种生产问题，某种代码片段开始产生共鸣。如果它们是分离的，它会减少共鸣。

当然。是的，这是真的。但是有不同的方法。我曾经在一家公司工作过，他们有一个代码库，我认为是单一的，但仍然部署为不同的服务，对吧？不是出于那个原因。

他们需要不同组件的不同规模。所以底层的代码库是统一的。无论发生什么变化，比如新的部署，我们都会重新定义所有服务，没有例外，但仍然能够获得设计错误成本较低的好处，以及某种程度上减少运营故障的好处。

你能分享一个你发现人们固执己见，坚持他们分离微服务的决定，因为他们读过某本书，认为这是正确的架构，而你不知道你在说什么的案例吗？你如何处理这样的人？

通常情况下，当他们联系我时，这些人已经离开了公司。

停止得很好。

也许他们得到了晋升，这样他们……

可以……是的。

阿尔伯特……

原则上，向上移动以管理……

是的，我明白了。但你显然在某些时候经历过和推迟，对吧？当然。

是的，但与此同时，他们并没有联系你。事情进展顺利。是的，是的，他们从未为此联系过我。嘿，想付你的费用，带你一周来展示一切进展顺利，我想起了罗伯特。

艾尔文和不可能的餐厅，他如何进入这些失败的餐厅，他们坚持说我的食物很棒，就像，是的，我可以告诉你一个顾客喜欢……

好吧，如果我们谈论阻力，那么我会回到领域驱动设计的话题，因为出于某种原因，领域驱动设计获得了过于复杂，模式太多这样的声誉。

如果你……如果它看起来……是的。

现在，一旦你遇到这种阻力，我通常的做法是，我开始谈论领域驱动设计的原则，而无需提及领域驱动设计，无需提及具体的模式。嗯，好吧，我们有这个问题需要解决。所以这是问题的根本原因。

现在，也许你想头脑风暴一下我们可以做些什么。有一个家伙发明了聚合模式，但用不同的名字。但他很高兴。

我说，好吧，没问题。让我们继续这个电话。它，无论你想要什么。

是的，是的，鲍勃的模式。但是，你知道，人们有自己的偏见。所以，如果你不使用这些词，但仍然取得成果，那么也许以后会更好。

但这重要吗？目标是找到解决方法。维德，所以找到前进的方法。这些原则仍然非常有用。

原则，出于某种原因，我不知道为什么，但这种平衡耦合模型更容易让人们理解并开始使用。

我明白了，是的，我明白了四个层次。你只需要知道这些，是的，只是……

关于将你的问题分类到这些不同类别中的对话，然后你就有针对每种情况的不同方法策略。

几乎所有领域驱动设计模式背后都有这种平衡。例如，埃里克·凯文总是说，并非所有大型系统都是精心设计的。他的意思是，支持子系统并不那么重要。

在某些方面是可以的。关于运动腹部呢？它们不是业务关键的。

所以它们不会发生太大变化，这意味着它们的易变性要比核心子系统低得多。所以我们再次得到了平衡。我们可以引入一些复杂性，因为易变性较低。

但是当我们谈论高易变性子域时，当然，我们应该尽可能保持设计简洁。当然，我们有这些模式，例如边界上下文中的外来封装模型。而且你……

还在学习如何选择你的战斗，对吧？就像你让架构师们出来。绝对的。而且所有东西都必须以相同的方式构建，通过这个耦合实践来找出哪些地方实际上会成为问题，只为那些如果做得不好会造成最大伤害的地方而战。边缘情况可以稍微弱一些，因为后果很小，但是如果后果很大，那么你可以更努力地工作，花更多的时间，甚至进行评估，看看耦合会真正带来什么后果。分离它值得花时间吗？

你不需要为所有事情都这样做，是的。易变性，变化的维度或时间的维度在这里非常有帮助。因为一旦你发现了高易变性，但你如何评估易变性？不同的方法，不同的模型？我更喜欢我的领域驱动设计子域。但是一旦你发现了高易变性，那么你就有低悬的果实。

事情首先……是的，它也适用于当我们分配新应用程序部分时，我们看到高易变性。现在，我实际上对基于耦合方式应该在哪里重新分配有新的看法，至少最初我认为我们应该在与所有相关部分都密切相关的团队中开始。你知道，如果情况发生变化，我们可以稍后修改。尤其是在设计是一个新领域的时候。最小化距离会带来很多风险。

是的。好吧，让我们在这里平衡一下。并非总是可行的。

有时，当你最小化距离时，你正在引入复杂性，对吧？所以我总是尝试在该模块内至少建立逻辑边界，然后我们有距离。与最初的分布式模型相比，它肯定会显著降低。但是，我们仍然可以在该代码库内的不同模型中讨论不同的距离，在我们添加相同的模块、相同的逻辑边界之前，与该代码库内的不同逻辑边界相比，距离会更低。是的。

感谢你的理解。

很好。我们还有什么想讨论的吗？

在我们结束之前？还有更多内容。有不同程度的集成强度，对吧？

这是你说的需要一个小时才能解释的内容。

他们提供了更多细节，并且还帮助你识别那些特定情况，它如何运作。

耦合与模型耦合，对吧？好吧，弗拉德，够了。他的新书是关于软件设计的耦合平衡。

去看看吧。这是一个引人入胜的话题，我们已经开阔了视野。感谢你今天和我们谈话，弗拉德。

我们将……

下次在……

点……

网络岩石上与你交谈。

Dn rox 由富兰克林网络提供，由流行工作室制作，位于新伦敦的综合音频、视频和后期制作设施。当然，在线访问：apwop.com。

访问我们的网站，adotntrocks.com，获取 RSS 源、下载、移动应用程序、评论以及追溯到 2002 年 9 月第一期节目的完整档案，并确保查看我们的赞助商。他们让我们的节目能够继续。现在，去写一些代码，CNX 时间。

最好的夏天。

你真是乱。

瑞安在这里，我有一个问题要问你。你赢了之后会做什么？比如，你会拍拍屁股走人吗？

如果你想尝试这些获胜的策略，请查看 MBA Casino 200 多种社交风格游戏，有机会赢得丰厚的现金奖励。每周都会有新游戏发布，每天还有免费奖励。所以不要犹豫，在 Champ Casino 玩得尽兴吧。

黑色星期五就要到了。对于你生活中热爱最酷玩具的成年人来说，今年也有适合他们的东西。Martin是首屈一指的手工鸡尾酒制作师，它可以自动制作超过六十种季节性和经典鸡尾酒，只需按一下按钮，即可在三十秒内完成。

现在，教学正在进行大规模的促销活动。花四美元多一点，就可以获得一百美元或任何鸡尾酒或蛤蜊。如果你生活中热爱鸡尾酒的人今年表现良好，那么所有正确类型的坏事都将发生。让他们在按钮一按即可制作出各种糟糕品质的宇宙鸡尾酒、曼哈顿鸡尾酒等等，所有这些都在短短三十秒内完成，所有这些都只需一百美元的惊人玩具，并不仅仅是孩子们的玩具。在网络星期一之前花四百美元购买一个鸡尾酒制作器，访问aboutteaching.com或flashcocktail.bartesian.com。