限定上下文BC

“单体与微服务”的争论通常集中在技术方面，而忽略了战略和团队动力。但是，思维敏捷的组织不是从技术入手，而是以团队的认知负担作为有效交付和运行现代软件系统的指导原则。 

“企业资源计划系统”（ERP系统）之类实际上是一种瑞士军刀软件系统。毫无疑问，它们确实是功能强大的工具，但是在某些情况下，它们可能造成的弊大于利。因此，我想讲一个虚构的故事，该故事显示了组织如何陷入困境。为此，我将尝试使用Nick Tune的全新

人们通常不知道微服务需要独立的自治。例如各种服务共享一个数据库；另一个问题是，服务之间通过RPC/Restful进行网络之间的同步调用链太长。这些都是分布式意大利面条一样的糨糊结构，这种架构并没有引起人们的注意，这种面条糨糊的结构可能是由于各种相互调用的服务紧密耦合而引起的。设计微服

DDD不是聚合、事件溯源、CQRS、事件风暴等。这些都是工具。它们已被证明在DDD项目中非常有用。但是我们必须小心，不要将演奏乐器与音乐艺术混淆。对我而言，这是DDD的关键是：与大型系统的复杂性作斗争时，项目团队如何获取领域知识，他们如何构建、开发和普及应用概念模型，以及随着时间的推

这是业务分析师面临的共同挑战。业务分析师如何确保任何发现流程都能产生完整的结果？简短的答案是使用多种补充技术从不同角度解决问题，每个角度相互验证并填补发现过程中的所有空白。有一些软件工具可以自动发现和记录业务流程。这通常称为流程挖掘。但是，直到较小的公司可以使用这些工具（降低成本）之前，许多

基于模型的管理是指基于从记录当前状态的模型中收集并理解信息，管理和做出有关业务，流程或系统的未来方向的明智决策的活动。最近，术语“基于模型的管理”已越来越有规律地用于描述战略业务计划中模型的使用。重点已放在模型的重要性上，因为它与捕获企业结构，运营，系统以及其运营所在的经济环境的复杂

“容器”一词已成为一个非常频繁的名词，常常引起混乱。这里试图精确定义，意味着四个意思：一：以容器为隔离机制。在Linux上，这是可用于隔离进程或进程组的cgroup，seccomp和friends的集合。二：容器作为包装机制。最流行的是Docker，涉及获取一些代码并关闭其依

时间和资源是有限的，在开发软件系统时，我们如何花费有限时间并利用有限资源解决最根本、最困难的挑战？在我们可能要做的所有事情中，我们应该做什么，我们应该投资多少质量和严格度？对于软件工程师来说，自然的趋势是倾向于迎接最有趣的“技术”挑战。尽管并非总是如此，但我可以从自己的亲身经历中确认

构建微服务很容易，难点是：-找到微服务之间适当的界限-集成服务（消息传递与RPC）-错误处理（弹性）-Sociotechno社会技术的关注（团队划分界限，组织变更）  

在软件设计中，“越小越好”几乎普遍是坏建议，例如针对数据库分区，消息大小，μsvcs，有界上下文，类名，方法一致性等。一些关键业务逻辑会越过这些细粒度边界，并导致实施不当。小粒度事物看起来很简单，因为错误不是隐藏在事物内部，而是隐藏在它们的连接中。 事物边界会变大，很少变小或

如果您的公司建立在单体monolith之上。由于您的业务知识在内部传播，因此这种单体monolith可能是您的最佳资产，但是由于多年的技术债务和团队在相互沟通的情况下发布代码，这些是脏的。单体程序缓慢，不透明，容易出错，未经测试。发布新代码时开发人员和sysops团队都开始担心，因此

只有我发现使用foo和bar的编程示例极其无助且令人困惑吗？请写出真实的词，这可能有助于我解释“ foo”可能做什么的含义。 众说纷纭：我通常觉得foo / bar通常与假定的知识解释结合在一起。

围绕一个系统的某个区域的活跃的领域知识才是有保存价值的基本单位，但是这容易被破坏隔离，领域的知识连续性很重要，DDD的有界上下文概念似乎是一个很好的基础。 (特性团队是跨专业的, 面向最终用户交付完整价值的团队，组件团队Component Team

EventStorming是一种非常流行的技术，它使我们比传统技术更有效地探索，分析和建模业务领域。由此我们可以创建与设计更好的软件系统和问题解决方案。明智地使用EventStorming，我们可以发现有关我们的域和业务的足够信息，以便我们可以使用它来设计微服务，有界上下文甚至我们的

领域驱动设计的作者埃里克·埃文斯（Eric Evans）在前几天Explore DDD上的主题演讲中，邀请听众积极参与改进在建模和设计复杂系统时使用的语言。埃文斯（E