如果您这些年来一直在企业软件体系结构的任何地方工作，您很有可能会遇到诸如“什么是微服务的正确粒度？”之类的问题。或“微服务和有界上下文是否相同？”
如果您这些年来一直在企业软件体系结构的任何地方工作，您很有可能会遇到诸如“什么是微服务的正确粒度？”之类的问题。或“微服务和有界上下文是否相同？”
在接下来的几段中，我将尽力澄清。
我想澄清的第一个问题是，两个概念都有一个模糊的定义。定义这些概念本身已经很困难，因此将两者结合起来很容易使对话变得含糊不清。
领域驱动设计的发明者埃里克·埃文斯（Eric Evans）可能需要花费数天的时间寻找完美的词语来传达特定的含义，因此当他选择一个词时……这个词只是可能代表他表达含义。因此，让我们看看Context的原始定义，然后再看看有界上下文Bounded Context（原始资源在这里）：
上下文：用来确定其含义的单词或陈述的一种设置
这基本上是一个语言术语。关于世界各地的“ 咖啡 ”一词的不同含义，有无数的故事和笑话，但这就是任何语言的本质。术语如果在其原始范围之外被使用，最初听起来像很奇怪的隐喻，逐渐这也成为对话语言的一部分，依此类推。
但是语言只能在一定程度上帮助我们：编写软件时，我们需要精度。当开发涉及多个上下文的软件时，使某些对话听起来像是在开玩笑的同样模棱两可的情况，将成为错误的危险来源。
在软件世界中，我们需要承担为这种语言一致性设置边界的责任。这就是“ 有界上下文”概念出现的地方。
有界上下文：特定模型的有限适用性。有界上下文使团队成员可以有一个清晰的、共享地理解，这就是那些独立开发的内容必须保持一致性。
这里的定义更接近软件开发领域。有一些隐含的假设，让我们尝试使其明确。
实际上，有界上下文使用这种语言作为煤矿中的金丝雀（banq注：用金丝雀测试煤矿中是否有毒气，它们比较敏感，这也是测试领域的一个专业词语：金丝雀测试）：语言对于来自不同来源（团队成员，利益相关者，团队分布，基础技术，时间等）的变化非常敏感。语言中会出现不一致之处，因此我们会留意。
保留边界成为一项有趣的设计活动，因为它意味着通过实现适配器或反腐败层来推动边界处的转换，以使内部模型尽可能简单，或者更好地专注于该特定模型的唯一相关问题。
（banq注：边界敏感性和文化思维方式有关，如果文化中注重个人隐私边界，会培养成对事物和人的边界划分敏感性，如果没有这种文化，注重邻里和谐打成一片，对培养边界敏感性可能不利）
当要确切地了解微服务是什么时，由于没有单一的中央定义要引用，因此情况甚至更加严峻。但是，Martin Fowler’s Bliki 仍然可以作为权威信息来源。
该术语严格来说是架构性的，但有趣的是，其含义正在整个社会技术体系中产生。
在这里，我试图将两个概念的关键特征重叠起来。
特征有界上下文微服务兼容性
这两个概念一样好像感觉不同但高度兼容。
它们不是同一件事：
在年轻的初创公司中，开发速度非常重要，因为我们要从头开始构建许多组件，但是物理隔离不同的组件会减慢一切，并且在快速增长的环境中，边界可能会模糊一段时间。常见的策略可能是在整体内部进行逻辑隔离，并仅在达到给定数字时才开始发展体系结构。
在中型公司中，不同的团队已经可以与定义明确的部门合作。目的驱动的边界可能与部署单元以及业务功能重叠。
在某些情况下，可以通过具有多个独立模块的松散耦合组件来实现价值交付。在这种由Netflix闻名的场景中，组件比有界上下文小得多，并且通过诸如Chaos Engineering（Chaos Monkey和Simian Army是著名的例子）之类的激进方法来保持整体行为的完整性，以增强整个系统。
我喜欢渐进式架构的想法，而不是预先进行大型设计。(banq注：敏捷？)
有界上下文应围绕目标和语言边界出现。战略愿景的事件风暴是突出并收集这些边界的一种非常有效的方法。
微服务通常会在团队规模和变更频率附近找到独立部署单元的最佳规模。最终部署在一起的拆分组件往往会因协调成本而适得其反，因此自主团队倾向于找到自己的完美平衡。
错误大小的动态是不同的：太细粒度的有界上下文很容易混合，而分离这些已经混合的BC有界上下文则要贵得多。
微服务暴露出相反的风险结构：过于细粒度的服务会增加保持整体结构受控的成本，而将服务拆分成更明确的结构（可能保留前端API）则可以在分析实际服务后按需完成压力。
这种相反作用力的结合通常要求：逻辑上保持边界整洁，在有价值的时候进行物理隔离。
数据驱动的拆分（无需进行对业务行为的检查和重新设计即可将数据库表的应用直接转换为微服务）也产生了惊人的反作用：新系统与其整体祖先耦合在一起，但速度可能较慢，并且重构成本飞涨。
大多数从业者都担心完美的尺寸和技术堆栈。但是真正有趣的属性是在社会技术堆栈的社会部分。
有界上下文为这种实验提供了隔离的空间。隔离是提供安全的基础。如果您的模型与太多的参与者共享，人们将无法进行实验，因为会破坏他人的代码。
良好的有界上下文提供了安全的空间和良好的责任循环。
我们是对此类代码负责的唯一人员。如果这里有错误，我们不能怪任何人。但是我们可以确保代码中完全没有错误。
这种不依赖其他团队或其他技术的小技巧，与考虑周全的微服务似乎朝着同一方向发展，在反馈循环中增加了一些加速，因此领域学习和业务学习也可以通过生产影响快速得到验证。
对我而言，真正使我震惊的是，有界上下文和微服务与丹尼尔·平克（Daniel Pink）《驱动器》的动机原则是融合一致的：自治，精通和目标。
换句话说：我们一直在技术和工程方面，因为这是我们擅长的，我们可能会忘记我们只是在为软件专业人员建立一个更健康的工作场所。,如果您这些年来一直在企业软件体系结构的任何地方工作，您很有可能会遇到诸如“什么是微服务的正确粒度？”之类的问题。或“微服务和有界上下文是否相同？”
在接下来的几段中，我将尽力澄清。
我想澄清的第一个问题是，两个概念都有一个模糊的定义。定义这些概念本身已经很困难，因此将两者结合起来很容易使对话变得含糊不清。
领域驱动设计的发明者埃里克·埃文斯（Eric Evans）可能需要花费数天的时间寻找完美的词语来传达特定的含义，因此当他选择一个词时……这个词只是可能代表他表达含义。因此，让我们看看Context的原始定义，然后再看看有界上下文Bounded Context（原始资源在这里）：
上下文：用来确定其含义的单词或陈述的一种设置
这基本上是一个语言术语。关于世界各地的“ 咖啡 ”一词的不同含义，有无数的故事和笑话，但这就是任何语言的本质。术语如果在其原始范围之外被使用，最初听起来像很奇怪的隐喻，逐渐这也成为对话语言的一部分，依此类推。
但是语言只能在一定程度上帮助我们：编写软件时，我们需要精度。当开发涉及多个上下文的软件时，使某些对话听起来像是在开玩笑的同样模棱两可的情况，将成为错误的危险来源。
在软件世界中，我们需要承担为这种语言一致性设置边界的责任。这就是“ 有界上下文”概念出现的地方。
有界上下文：特定模型的有限适用性。有界上下文使团队成员可以有一个清晰的、共享地理解，这就是那些独立开发的内容必须保持一致性。
这里的定义更接近软件开发领域。有一些隐含的假设，让我们尝试使其明确。
实际上，有界上下文使用这种语言作为煤矿中的金丝雀（banq注：用金丝雀测试煤矿中是否有毒气，它们比较敏感，这也是测试领域的一个专业词语：金丝雀测试）：语言对于来自不同来源（团队成员，利益相关者，团队分布，基础技术，时间等）的变化非常敏感。语言中会出现不一致之处，因此我们会留意。
保留边界成为一项有趣的设计活动，因为它意味着通过实现适配器或反腐败层来推动边界处的转换，以使内部模型尽可能简单，或者更好地专注于该特定模型的唯一相关问题。
（banq注：边界敏感性和文化思维方式有关，如果文化中注重个人隐私边界，会培养成对事物和人的边界划分敏感性，如果没有这种文化，注重邻里和谐打成一片，对培养边界敏感性可能不利）
当要确切地了解微服务是什么时，由于没有单一的中央定义要引用，因此情况甚至更加严峻。但是，Martin Fowler’s Bliki 仍然可以作为权威信息来源。
该术语严格来说是架构性的，但有趣的是，其含义正在整个社会技术体系中产生。
在这里，我试图将两个概念的关键特征重叠起来。
特征有界上下文微服务兼容性
这两个概念一样好像感觉不同但高度兼容。
它们不是同一件事：
在年轻的初创公司中，开发速度非常重要，因为我们要从头开始构建许多组件，但是物理隔离不同的组件会减慢一切，并且在快速增长的环境中，边界可能会模糊一段时间。常见的策略可能是在整体内部进行逻辑隔离，并仅在达到给定数字时才开始发展体系结构。
在中型公司中，不同的团队已经可以与定义明确的部门合作。目的驱动的边界可能与部署单元以及业务功能重叠。
在某些情况下，可以通过具有多个独立模块的松散耦合组件来实现价值交付。在这种由Netflix闻名的场景中，组件比有界上下文小得多，并且通过诸如Chaos Engineering（Chaos Monkey和Simian Army是著名的例子）之类的激进方法来保持整体行为的完整性，以增强整个系统。
我喜欢渐进式架构的想法，而不是预先进行大型设计。(banq注：敏捷？)
有界上下文应围绕目标和语言边界出现。战略愿景的事件风暴是突出并收集这些边界的一种非常有效的方法。
微服务通常会在团队规模和变更频率附近找到独立部署单元的最佳规模。最终部署在一起的拆分组件往往会因协调成本而适得其反，因此自主团队倾向于找到自己的完美平衡。
错误大小的动态是不同的：太细粒度的有界上下文很容易混合，而分离这些已经混合的BC有界上下文则要贵得多。
微服务暴露出相反的风险结构：过于细粒度的服务会增加保持整体结构受控的成本，而将服务拆分成更明确的结构（可能保留前端API）则可以在分析实际服务后按需完成压力。
这种相反作用力的结合通常要求：逻辑上保持边界整洁，在有价值的时候进行物理隔离。
数据驱动的拆分（无需进行对业务行为的检查和重新设计即可将数据库表的应用直接转换为微服务）也产生了惊人的反作用：新系统与其整体祖先耦合在一起，但速度可能较慢，并且重构成本飞涨。
大多数从业者都担心完美的尺寸和技术堆栈。但是真正有趣的属性是在社会技术堆栈的社会部分。
有界上下文为这种实验提供了隔离的空间。隔离是提供安全的基础。如果您的模型与太多的参与者共享，人们将无法进行实验，因为会破坏他人的代码。
良好的有界上下文提供了安全的空间和良好的责任循环。
我们是对此类代码负责的唯一人员。如果这里有错误，我们不能怪任何人。但是我们可以确保代码中完全没有错误。
这种不依赖其他团队或其他技术的小技巧，与考虑周全的微服务似乎朝着同一方向发展，在反馈循环中增加了一些加速，因此领域学习和业务学习也可以通过生产影响快速得到验证。
对我而言，真正使我震惊的是，有界上下文和微服务与丹尼尔·平克（Daniel Pink）《驱动器》的动机原则是融合一致的：自治，精通和目标。
换句话说：我们一直在技术和工程方面，因为这是我们擅长的，我们可能会忘记我们只是在为软件专业人员建立一个更健康的工作场所。